Multi-tenant platforms

The tenancy model

An organization contains projects, and every project carries exactly two environments — sandbox and production — created with it. Plans do not cap the number of projects in an organization: add one per end customer. An API key belongs to exactly one project and environment, and everything created with that key — messages, contacts, templates, webhook endpoints, phone numbers, provider connections — is scoped there. Tenant isolation is therefore the project boundary: one tenant's key cannot read or affect another tenant's data.

Each project's production environment holds its own Meta WhatsApp connection with its own WABA (one active Meta WhatsApp connection per environment). Nothing limits how many WABAs one organization spans — ten projects with ten different WABAs is the expected shape, not a special case. Each project's sandbox environment gives that tenant's integration a free simulated loop before go-live.

What is programmatic today — and what is not

Stated plainly, because it decides your onboarding flow:

• Creating an organization happens at first dashboard signup. There is no public API for it, and one account starts with one organization.
• Creating a project is dashboard-only today. There is no public endpoint to create a project or an environment.
• Minting API keys is programmatic, with one bootstrap step per project. POST /v1/api-keys requires the api_keys:adminscope, and that scope is only granted from a dashboard session — an API key can never mint another api_keys:adminkey. A key also always mints into its own project and environment; there is no cross-project minting. So the pattern is: create the project in the dashboard, create its first admin key in the dashboard, then mint, rotate, and revoke that tenant's operational keys programmatically from then on.
• Connecting each tenant's WhatsApp is programmatic. POST /v1/meta-signup-sessions creates a hosted Meta Embedded Signup session you can hand to the end customer inside your own product; pass end_customer_ref, and the meta_signup_session.completed webhook tells you which tenant finished. Details on the Provider connections API page.
• Everything after bootstrap— webhook endpoints, templates, contacts, sends, usage reads — is public API with that project's keys.

Webhooks across tenants

A webhook endpoint is registered with a project + environment API key and receives only that environment's events. Endpoints are environment-scoped and there is no organization-wide endpoint, so an integration spanning several projects registers one endpoint per project and environment.

Delivered payloads carry no organization or project ids: the envelope's environment field is the kind — sandbox or production— not an id. Route events to the right tenant by the receiving URL: give each project's endpoint its own path or subdomain, which also gives each tenant its own signing secret. Inside payloads you additionally get metadata you attached to outbound messages echoed back on message events, the receiving number's id on message.received (in production WhatsApp this is the opaque Meta phone_number_id), and end_customer_ref on meta_signup_session.completed. The delivery contract itself is on the Webhooks page.

Billing across tenants

Billing attaches to the organization, not the project. One prepaid BRL credit balance and at most one subscription cover the whole organization: the plan's per-message transport discount applies to traffic from every project and environment, so a single subscription covers all tenants — there is no per-project plan or wallet. The production phone-number allowance is also organization-wide: it counts active production numbers across all projects, whichever WABA each number belongs to. Plans and rates are on Billing.

Per-tenant attribution still exists: usage read through a project's key (GET /v1/usage, GET /v1/usage/records) reports that key's environment only, invoices are generated per project, and a monthly spend limit can be set per project in the dashboard.

Meta's own conversation charges never route through Tyxter: Meta bills the owner of each WABA directly. When each end customer connects their own WABA, Meta's charges land on that end customer's own Meta account, and Tyxter bills your organization only its transport fee. Ownership and exit paths are on Tyxter and Meta.

Identity and compliance

Business-identity verification (KYC) is organization-level: one legal entity — your CNPJ — covers every project and environment, and your end customers never go through Tyxter KYC. Messaging through customer-owned WABAs and bring-your-own-number connect (POST /v1/phone-numbers/connect) are never gated on identity verification; it is required only when Tyxter provisions a Brazilian number for you or for production Agentic Payments, and it is self-declared and instant. Details on Business identity.

A data processing agreement is available on request, and the current service-level posture is stated plainly on Support & service levels. Read those two plus Trust & security and Data retention & privacy (the controller/processor split and the retention and export controls) before a vendor or LGPD review.