Trust & security

Where your data lives

That statement is about the data Tyxter stores. It is deliberately not the broader claim that everything stays in the country, because the subprocessors below each process what they receive in their own locations under their own terms, and WhatsApp delivery in particular runs through global Meta infrastructure. The accurate version is that the datastores Tyxter runs are in Brazil.

Subprocessors

These are the third parties that process customer data in the Tyxter product surfaces, and what each one receives. Infrastructure and transport-level providers are covered by the on-request documentation below.

AI vendors you bring yourself are not on that list, on purpose. Automated replies and voice synthesis run on your own provider account with your own key, so the conversation text goes to the vendor you chose under the contract you signed with them, not under one of ours. Tyxter passes the request through and never substitutes a different provider.

Data processing agreement

A data processing agreement is available on request. Ask through the channels on the Support & service levels page and name the legal entity it should be issued to. Which side is controller and which is processor, what Tyxter keeps, for how long, and the retention window and export switch you control yourself are set out on the Data retention & privacy page.

How the platform is secured

Credentials and secrets

The provider credentials Tyxter holds for you — the Meta access token, payment provider keys — are encrypted at rest with AES-256-GCM, are never returned in an API response, and are never written to a log. Stored credential envelopes carry a key version, so the encryption key can be replaced without losing the ability to read what was written under the old one.

Tyxter service secrets are supplied at runtime and are never committed to source control.

Webhook endpoints you own

Each webhook endpoint you register gets its own signing secret, stored field-encrypted. Its plaintext is returned once, when the endpoint is created, and once more if you rotate it — each rotation mints a new secret, itself returned once. It is never returned on a read, a list, or an update. How deliveries are signed, how replay is prevented, and how retries behave are on the Webhooks page.

Because you supply the destination URL, the delivery worker is an obvious lever for reaching infrastructure it should not reach. It refuses plain-HTTP URLs carrying credentials, refuses localhost, private, and link-local addresses, and re-resolves and re-checks DNS immediately before each request — so a hostname cannot answer with a public address at registration time and a private one at delivery time.

Sandbox and production stay separate

An API key prefix decides its environment and nothing in a request can override it: tx_sandbox_ keys reach only the sandbox environment, tx_live_ keys only production. Sandbox messages are real-shaped but never leave the platform, so nothing you send while testing can arrive at a real recipient.

Queue jobs carry record identifiers, not payloads. Workers re-read what they need from the database, which keeps message content and personal data out of the queue system.

Infrastructure and deploys

The production origin is not directly exposed to the internet and sits behind a hardened perimeter. Changes ship through a gated, automatically verified deploy process.

Sessions and vulnerability reports

Dashboard sessions are ES256-signed JWTs valid for 30 days, and every protected request re-checks the token against a durable session version, so signing out or changing credentials invalidates older tokens immediately. The private signing key never leaves the API process; only the public verification key is published.

Report a suspected vulnerability to the security contact published in machine-readable form at /.well-known/security.txt on the Tyxter site root. It resolves to the same support address as the rest of the Support & service levels page.

Detailed infrastructure and operations documentation — hosting provider, network architecture, backup and recovery procedures, and the full vendor list including transport-level providers — is available on request through the support channels on the Support & service levels page.

Durability and recovery

Postgres is the source of truth. Redis and the job queues are execution infrastructure: durable state, lifecycle evidence, idempotency records, and billing ledgers all live in the database, so losing queue state loses scheduling, never history.

A state change and the event that announces it are written in one database transaction, so a crash between the two cannot leave async work orphaned — either both landed or neither did. From there, one trace ID follows the whole operation: API request, database rows, queue job, worker logs, webhook event, billing ledger entry. One identifier from a failing response is enough for us to reconstruct what happened.

Webhook redelivery is built to survive a crash rather than to assume none happens. A delivery is claimed atomically before the outbound request so two workers cannot both send it, attempts are append-only, the next attempt row is written in the same transaction as the state change that schedules it, and a reconciliation sweep re-enqueues deliveries stranded mid-flight.

Automated daily backups are stored redundantly off the primary host.

Live component health, and the record of past incidents, are on the System status page. What Tyxter does and does not promise about availability is on Support & service levels.

Audits and certifications

What this page offers instead is a specific description of the controls that do exist, and a named channel to ask about any of them. If your review needs an external report before you can integrate, raise it by email before you build rather than at contract stage.