Trust & security
What a vendor review asks before you send production traffic through Tyxter: who else touches your data, where it is stored, what Tyxter will sign, how the platform is secured, and what survives a machine dying.
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.
| Vendor | What it does | What it receives |
|---|---|---|
| Meta Platforms | Message delivery on the WhatsApp Business Platform and Instagram | Recipient phone numbers and account identifiers, message content, media, templates |
| Salvy | Brazilian virtual mobile numbers for platform-provisioned lines | The provisioned number, and carrier SMS relayed to it such as verification codes |
| Stripe | Card payments, saved cards, and plan subscriptions | Cardholder data, name, email, phone, tax ID, billing address |
| Abacate Pay | Pix top-ups of your Tyxter credit balance | Payer name, tax ID, email, and a phone number when you supply one |
| Iniciador | Open Finance payment initiation for bank-authorized Pix payments | Payer name, tax ID, and the bank and account chosen for the payment |
| BrasilAPI | CNPJ registry lookup during business identity verification | The CNPJ you submit, digits only |
| Resend | Transactional email: sign-in links, alerts, invoices | Recipient email, name, message body |
| Cloudflare | Network ingress, DNS, and bot filtering for public traffic; hosting for the public status page; plus page-level performance and usage telemetry via an edge-injected analytics beacon on every visit | Your HTTP traffic to Tyxter in transit, and the browser telemetry that beacon reports from every dashboard and website page |
| PostHog | Product analytics for the Tyxter dashboard | Autocaptured browser usage events — page URLs, clicks, device and browser metadata — from every dashboard visitor, including before sign-in |
| Optional social sign-in; web fonts on the dashboard and website; advertising measurement on the public website; the embedded walkthrough video in the dashboard onboarding tour and on the public website | For sign-in, your account email, name, and provider account ID. For fonts, advertising measurement, and the embedded video, visitor IP address, browser user agent, page URL, and cookies | |
| GitHub | Optional social sign-in | Account email, name, provider account ID |
| OpenAI | The dashboard support assistant, platform-drafted message templates, and speech-to-text for environments that have not connected their own OpenAI key | The text you write into the assistant and the template drafter, and the audio of a message you ask Tyxter to transcribe while no OpenAI key of yours is connected |
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. Speech-to-text is the one capability with a platform fallback: connect your own OpenAI transcription key and the audio goes out under your account; leave it unconnected and it goes out under Tyxter's. Every path by which message content reaches a third party, and what Tyxter itself does and does not do with content, is stated at /data-processing.
Data processing agreement
A data processing agreement is available on request. Ask through the channels at /support 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 at /data-retention.
Capabilities you can switch off
This is the answer to the questionnaire item that asks whether a tenant can be prevented from using a capability at all. It is a stronger control than a narrowly scoped API key, because a scope is chosen by whoever mints the key and a switch is not: once a family is off, no key minted afterwards can reach it. A blocked call answers 403 with error.code feature_disabled. Which families exist, what each one covers, and how the switches are administered are at /feature-controls.
What this does not claim: dashboard product pages for signed-in members of your own organization are deliberately left ungated, so an owner who turns a family off can still see and undo that configuration through the surface that configures it. The control governs the programmatic surfaces — API keys and MCP tool calls — which is where an integration, an agent, or a leaked credential would act.
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 at /webhooks.
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 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 at /support.
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 at /status. What Tyxter does and does not promise about availability is at /support.
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.