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 programmatic for a scoped API key. POST /v1/projects requires projects:writeand creates the project's sandbox and production environments. It is organization-scoped: it never selects or creates a project in another organization.
• Minting API keys is programmatic after one dashboard bootstrap for an administrative source key. 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:admin key. Omit project_idto mint in the source key's current project. To bootstrap an active sibling, supply its project_id; Tyxter chooses that project's environment of the same sandbox or production kind. The source key can delegate only scopes it already holds, never crosses organizations, and cannot cross the sandbox/production boundary. So the pattern is: create the project, then use an administrative source key to mint that project's operational key programmatically.
• 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

Webhook registrations remain scoped to the organization, project, and environment of the API key that creates them; an integration spanning several projects still registers one endpoint per project and environment. One receiver URL may be reused across environments, projects, or organizations. Each registration has its own endpoint-specific signing secret, so the receiver must select the secret for the endpoint that sent the request rather than routing or selecting a secret by URL.

Delivered payloads carry no organization or project ids: the envelope's environment field is the kind — sandbox or production— not an id. Use the endpoint-specific signing secret and your registration mapping for receiver configuration; receiver URL reuse is supported. Inside payloads you additionally get metadatayou 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.