Encryption

What the SDK encrypts for you, and what remains your responsibility.

What the SDK does for you

Before sending, the SDK encrypts the message body and the files in your application (AES-256), with a key generated for each send. The server that stores your messages never receives this key. You never handle a key.
To talk to the API, the SDK sets up with Secure Exchanges, for each operation, a separate session key, through a post-quantum key exchange (ML-KEM-1024) authenticated by an ML-DSA-87 signature, on top of HTTPS. It protects the call parameters, such as the recipients, the subject and the file names, which Secure Exchanges reads to route the message. It does not encrypt the content.
In transit, every connection uses HTTPS, with certificate validation.
When reading, the SDK decrypts the message and the files for your application.

So you have nothing to encrypt yourself to send, receive or get a document signed.

Topic	What to do
Credentials	Keep them in a secret manager. See Credentials and environments.
Decrypted content	What your application reads or downloads is in plain text on your side: store it encrypted, restrict who can access it, and delete it as soon as it is no longer needed.
Most sensitive content	Protect the message with a password that you give the recipient through another channel: Secure Exchanges never receives it.
Subject and file names	Secure Exchanges reads them to route the message: do not put personal information in them.
Logs	Never write decrypted content, a message password, an SMS code or a secure link to them.
TLS certificates	Never disable their validation. See Security and best practices.