Data processing

What Tyxter does with message content

For basic messaging, Tyxter handles text bodies, media, and interactive replies in four ways:

• Stored in the Postgres database and the object store Tyxter operates, so you can read it back through the API, the dashboard, and webhooks, and so delivery can be retried.
• Delivered to the WhatsApp Business Platform on the way out, and accepted from it on the way in. Meta is the channel, and it processes what it carries under its own terms.
• Returned to you through GET /v1/messages, the message.received and related webhook events, and the dashboard.
• Redacted in place once the message is older than the retention window you set, or immediately when you erase the contact.

Optional features can also send content to the vendors described below. Tyxter does not:

• routinely read, classify, moderate, or score message content, inbound or outbound, beyond the opt-out check below;
• filter profanity, links, or prohibited topics, or block a send because of what it says;
• scan media for malware or classify images, audio, or documents;
• use message content to build analytics, train models, or improve the product;
• feed message content into any operator tooling — the internal projections Tyxter staff work from carry counts, statuses, and identifiers, never content columns, and application logs never carry a message body.

The one automatic check

One automatic inspection runs on inbound content, always, in every environment: the opt-out keyword check. The text body of each incoming WhatsApp message is trimmed, lowercased, and compared as a whole against a short fixed list of opt-out words (such as parar, sair, cancelar, stop). Only an exact whole-message match counts; a message that merely contains one of the words does not. A match records an opt-out on the contact with source inbound_keyword, emits contact.opted_out, and blocks later sends to that number with contact_opted_out until you opt the contact back in. The matched word is stored on the contact's consent record, which is exempt from the retention window because a consent decision must outlive the conversation that produced it.

Nothing else is evaluated automatically. Two further checks exist, but only because you configured them, and both run before any vendor is called: an AI agent's blocked-topic rules and handoff phrases are matched against the inbound text so the conversation can be refused or handed to a person without the model ever seeing it. Those rules are yours — Tyxter ships none of its own.

When content leaves Tyxter

The paths by which end-customer conversation content can reach a third party are listed below. Apart from WhatsApp delivery itself, each one is a feature you enable, and most run on an account you own.

Two more integrations send text to OpenAI on Tyxter's own account — the dashboard support assistant and platform-drafted message templates — but they send the text a dashboard user typed into those features, never end-customer conversation content.

If you need to keep speech-to-text off Tyxter's vendor account, connect your own OpenAI transcription key under Connections → Speech-to-Text; the platform credential is used only when no key of yours is present. The optional capability switches available for an environment are described at /feature-controls.

Access by Tyxter staff

Tyxter staff do not routinely read your message content. Support, operations, and abuse tooling are built on metadata — statuses, timestamps, identifiers, delivery errors, counts — and the internal read surfaces exclude content columns by design.

A person at Tyxter accesses message content in three situations only, each bounded the same way: the access is limited to the messages or the time range the situation names, and it never extends how long the content is retained.

1. At your request. An organization owner or admin asks Tyxter in writing to look at specific content — typically to investigate a delivery or integration problem, or to assemble the evidence for an appeal against a Meta account action such as a messaging restriction or a ban. Tyxter reads only what the request names and shares its findings only with you.
2. Legal process. Tyxter receives a valid order from a competent authority. Tyxter reviews the order, discloses the minimum it requires, and notifies you before disclosure unless the law prohibits that notice. Tyxter does not disclose content voluntarily to any authority.
3. A platform-abuse or security incident. Tyxter is investigating suspected abuse of the platform — for example, before or after a suspension for the abuse patterns described in the terms of service. The investigation starts from metadata and delivery evidence. Content is examined only if the metadata cannot settle the question, and then only for the messages the evidence points at.

Outside those three situations, Tyxter declines requests for content.

What retention and erasure cover

The retention window and contact erasure apply to the content Tyxter derives from a conversation, not only to the message rows: speech-to-text transcripts, the source text of text-to-speech renders, AI agent and LLM response logs, and the run and step summaries an automation stores, including the raw inbound text an inbound-message trigger keeps so the automation can reply. Financial records, the consent ledger, and audit logs are exempt because the law or your own opt-out promises need them. The window, what redaction leaves behind, and the erasure endpoint are at /data-retention.

Building your own safety checks

Because Tyxter does not inspect content, any safety, compliance, or moderation rule is yours to run, and the platform is shaped so you can run it before a reply goes out:

• Inbound. Subscribe an endpoint to message.received; the event carries the text body, so your service can classify it and decide what to send back. Nothing is answered automatically unless you built the automation that answers.
• Outbound. Every send is your API call, so a check belongs in your code before POST /v1/messages. Broadcasts go through your audience and template choices, and the recipient's consent state is enforced on every send.
• AI replies. Put topics an agent must not discuss in its blocked-topic rules and phrases that should hand the conversation to a person in its handoff phrases; both are evaluated before the model is called. Review its response logs through the API while they are inside the retention window.
• Media. Tyxter checks a media file's declared type against the types WhatsApp accepts, and nothing else. Scan inbound attachments in your own pipeline if your policy requires it; the media descriptor on the inbound event tells you where to fetch the bytes.