Subprocessors

Hosts the SLDocs application, terminates TLS, routes requests, runs server-side code.

Data processed: All HTTP request data (IP addresses, headers, request paths, form submissions in transit).

Stores account records, document metadata, audit logs, billing records, and other structured data.

Data processed: User names, email addresses, hashed passwords, document filenames and metadata, recipient/trusted-contact records, billing records, audit log entries.

Stores user-uploaded documents as encrypted ciphertext blobs.

Data processed: AES-256-GCM-encrypted document ciphertext, KMS-wrapped data encryption keys (DEKs). No plaintext document content; the decryption keys are wrapped by Google Cloud KMS and never sent to R2.

Wraps and unwraps the per-document data encryption keys (DEKs) that protect document ciphertext. Operates the envelope-encryption layer.

Data processed: KMS-wrapped DEK blobs. The plaintext DEKs exist only in process memory during a single decryption operation and are zeroed afterward.

Sends authentication emails (verification, password reset, two-factor codes), invite emails, notification emails, and other transactional messages.

Data processed: Recipient email addresses, user names, message subjects and bodies, delivery metadata.

Processes B2C subscription payments, B2B firm billing, and one-time add-on purchases. Hosts the checkout flow and customer billing portal.

Data processed: Customer name, email, billing address, card / payment-method tokens. SLDocs never stores card numbers — Stripe handles them under PCI DSS.

Delivers documents by fax via Programmable Fax when a user purchases the fax-delivery add-on.

Data processed: Sender / recipient fax numbers and the document content being faxed. Plaintext document content is decrypted server-side, uploaded to a short-lived presigned URL (1-hour expiry, deleted after delivery), and provided to Telnyx.

Scans uploaded documents for malware before they are released into the user's vault. Documents are decrypted server-side and submitted to Cloudmersive for scanning; the plaintext is discarded after the scan returns a verdict.

Data processed: Document content (plaintext, transient) and scan result.

Captures unhandled server-side errors and exceptions from SLDocs application servers to help diagnose and fix bugs. SLDocs uses Sentry server-side only — no Sentry browser SDK is loaded, no cookies are set, and no client-side telemetry is collected.

Data processed: Server stack traces, error messages, the URL path and HTTP method of the failing request, and a small set of request headers. We do not send document content, encryption keys, full request bodies, or user PII to Sentry (sendDefaultPii is disabled). User IDs may appear in error context where strictly needed to reproduce an issue.