Security
What TextSend does to protect your Zendesk account, your Twilio credentials and your customers' phone numbers. The same facts appear in the privacy policy and the DPA; nothing here is a claim about Twilio's or Zendesk's platforms.
Authentication and authorization
- Twilio webhook signatures are always validated. Every inbound Twilio request is checked against its signature over a URL built from one configured base URL, never from request headers. A request that fails is rejected.
- Zendesk access uses OAuth. TextSend never asks you to paste a Zendesk API token into the app.
- Every backend request carries a verified app-identity assertion. The backend checks signature, issuer, audience, expiry and your Zendesk subdomain before it derives who the agent is and what their role allows. A role claimed by the browser is never trusted. If the key source is unreachable the request fails closed.
Infrastructure and credentials
- Twilio credentials live only in TextSend's secret store. They are accepted only by the backend, never returned to the browser on any response (including errors), can be rotated at once, and are deleted when deletion starts: usually about a week (7 to 8 days) after the app is removed, always within 30 days of removal.
- Tenant isolation by partition key, enforced twice. Every stored record is partitioned by your account; a mismatched cross-tenant read raises rather than returning data, and the database applies a row-level-security policy on top.
- TLS 1.2+ in transit to and from the backend and to its datastores over a private network. Encryption at rest is provided by the storage beneath each datastore.
- Guarded media fetch. Inbound MMS media is fetched from Twilio through a host-allowlisted, no-redirect, size-capped, content-type-checked fetcher.
- No platform-wide shared secret. Datastore credentials reach the service as projected secrets, never as image or manifest content; a build-time check asserts that.
Never logged or persisted
Message bodies, credentials, full media URLs and unredacted phone numbers, with one exception: whatever your admins type into a saved template (below). Two independent checks back this up: a storage guard refuses a stored value that is, as a whole, a phone number in international (+) format or a URL with a path, and anything under a free-text key; and every log or trace record passes a redaction filter that marks itself when it acts.
The one free text TextSend stores is your saved SMS templates: text your admins write on the Templates tab. Merge fields such as the requester’s first name are stored as placeholders and filled in by the agent’s browser when the template is inserted, so a template never holds a customer’s details unless someone types them in. Beyond refusing a name or body that is, as a whole, a phone number in international (+) format or a URL with a path, TextSend doesn’t check template text for phone numbers or other personal data, so keep it out of templates.
Retention and deletion
Deletion usually starts about a week (7 to 8 days) after the app is removed, and always within 30 days of removal: TextSend checks daily and starts 7 days after it first sees the app missing. When deletion starts, TextSend deletes your Twilio credentials and stops all processing. The remaining account data is purged within 30 days after deletion starts.
- Message text
- Not stored. Held in the processing queue only for the duration of the send or receive, then written to the ticket.
- MMS media
- At most 24 hours, temporary volume.
- Phone numbers, ticket references, delivery status
- Encrypted operational metadata. Deleted within 30 days after deletion starts.
- Opt-out records
- Kept while the app is installed so STOP keeps being honoured. After the app is removed, deleted within 30 days after deletion starts.
- Saved templates
- Kept until an admin deletes them. After the app is removed, deleted within 30 days after deletion starts.
- Twilio credentials
- Deleted when deletion starts, usually about a week (7 to 8 days) after the app is removed and always within 30 days of removal, or at once when you disconnect them.
Scanning and testing on every change
- Dependency scanning
- pip-audit (backend), npm audit (Zendesk app, admin console and this site)
- Secret scanning
- gitleaks over full history, fixtures included
- Static analysis
- bandit, semgrep, strict type checking in both codebases
- Tests
- Unit, integration and conformance suites, including tenant-isolation and secret-leak checks
- Infrastructure
- Formatted, validated, tested and linted before deploy
Compliance boundary
Reporting a vulnerability
Scope, safe harbour and response targets are on the vulnerability reporting page. Until a dedicated security address is set up, send reports to support@textsend.app with the subject line “Security”, so we can find them.