Tyxter Messaging Docs | WhatsApp API

Tyxter Messaging is the messaging product of the Tyxter platform. Use it to send transactional templates, run marketing broadcasts, receive inbound messages from WhatsApp users, and optionally hand automation off to an LLM you control.

These are the official Tyxter Messaging docs. Build from the routes and payload schemas in /openapi.json, /api-reference, and /llms.txt; public API calls use /v1/*.

Explore the docs

Quickstart →

Send your first WhatsApp message in under three minutes.

Sandbox →

Build end-to-end without touching a real number. No cost, deterministic IDs.

New customer setup →

Dashboard handoff, agent key quotas, and production readiness checks.

Webhooks →

Signed, retried delivery of every status change and inbound message.

API reference →

Full request + response shape for every endpoint, generated from the contract.

Status →

Live component health for the public Messaging API.

How it works

Tyxter Messaging is a modular monolith written in TypeScript. You talk to one HTTP API; we own the queue topology, the WhatsApp Cloud API integration, Brazilian number provisioning, billing, and the webhook delivery pipeline behind it.

Two environments, one key prefix

Every project has a sandbox environment and a production environment. Keys are strictly scoped by their prefix:

tx_sandbox_...  →  sandbox environment (free, deterministic)
tx_live_......  →  production environment (billed in BRL)

One HTTP base

Read the current API base URL from /.well-known/tyxter.json or from the servers list in /openapi.json.

Auth

Authorization: Bearer $TYXTER_API_KEY

Base URL: read api_base_url from /.well-known/tyxter.json or use the first server listed in /openapi.json. Public API calls use routes under /v1 as listed in the Tyxter OpenAPI document and API reference. Do not assume a hard-coded production host or invent routes outside the Tyxter discovery surfaces.

Authentication uses Authorization: Bearer <api_key>. Sandbox keys start with tx_sandbox_... and production keys start with tx_live_.... The key prefix must match the target environment.

Core objects: message, message_batch, media_asset, template, flow, contact, audience, phone_number, webhook_endpoint, payment_request, credit_balance, usage_record, and llm_route.

Core objects

Object	Description
`message`	An outbound or inbound WhatsApp message with its timeline of status events.
`message_batch`	A broadcast of one template to many recipients. Runs on an isolated queue.
`template`	Pre-approved marketing / utility / authentication copy. Submitted to Meta.
`flow`	A WhatsApp Flow form; submissions fan out as `flow.completed`.
`phone_number`	Salvy-provisioned or customer-connected WhatsApp number.
`contact`	Minimal consent ledger. Opt-out blocks sends to that phone.
`llm_route`	BYOK Anthropic/OpenAI configuration for inbound automation.
`webhook_endpoint`	Where we deliver events. Signed with HMAC-SHA256.

WhatsApp capabilities include inbound and outbound messaging, status webhooks, template lifecycle, broadcasts, contact consent, phone-number provisioning, and deterministic sandbox simulation. Payment request capabilities are available through the public API: create, list, retrieve, and request approval for BRL customer payment requests. Merchant provider generation runs asynchronously through the configured Abacate Pay connector, so new payment requests can briefly remain link_pending with payment_link_url = null. Pix providers may also return pix_copy_paste and pix_qr_code_base64.

Next steps

Follow the quickstart to send your first message.
Read how webhooks work before you move to production.
Browse the API reference for every endpoint.