Table of Contents

Security and best practices

The rules for every SDK integration: credentials, connections, error handling, logs and data validation.

Credentials

Never write them in code or commit them to a repository, and keep them in a secret manager. See Credentials and environments.

The .NET SDK also offers DataProtectionHelper to encrypt a credentials file on the server. On Windows, it uses DPAPI with machine scope: any process on the server can decrypt the file. So restrict its access to the service account, and prefer a secret manager when you can.

Connections

The SDK validates TLS certificates in production as in preview. Never disable this validation, not even for a test: a fake server could then receive your credentials and documents.

  • .NET: do not install a callback that accepts every certificate (ServerCertificateCustomValidationCallback).
  • Python: leave SettingsHelper.verify_ssl at its production value.
  • PHP: never pass verifySsl as false to the client.

Check every answer

Every call returns a status: check it before using the answer and, for a send, check each recipient's. Show your users a generic error message, and keep the details (status, tracking number) in your logs. See Status codes.

Do not send twice

A network error does not necessarily cancel a send: the timeout can expire after the message has already gone out. Do not resend automatically.

  • Retry only when the status shows the request was not processed (429, 503), with an increasing delay.
  • After a timeout, check the logs before sending again.

Logs

Log Never log
The operation, status, tracking number, time The API credentials
The number of recipients and files A message password, an SMS code
A recipient's secure link
The decrypted content of a message or file

Email addresses and phone numbers are personal information: mask them in your technical logs if you do not need them.

Validate data

  • Addresses and phone numbers: validate them before sending with IsValidEmailAddress and IsValidPhoneNumber.
  • HTML content: if the message contains data entered by someone, HTML-encode it before inserting it.
  • File paths: never use a path supplied by a user as is. See Attachments.

Environments

Never use your production credentials in a test environment: the preview environment has its own credentials. See Credentials and environments.

Next