Security model

Every credential and resource is tenant-scoped. Authentication identifies the caller; scopes and ownership checks decide what it can touch.

Credentials and authorization

• Secret API keys belong to one project unless an organization-scoped hosted MCP grant explicitly selects another project in the same organization.
• Publishable keys only create registration intents and are rate-limited by both key and source IP.
• Hosted MCP authorization and refresh grants are bound to the canonical MCP resource. Refresh tokens rotate on use.
• Hosted MCP bearer tokens are scoped to the MCP connector and cannot be used as REST API credentials.
• High-risk hosted MCP tools require person-controlled client elicitation. Trusted local stdio MCP uses explicit write mode and confirmation tokens.
• WebSocket subscriptions deliver only conversations the authenticated project is allowed to access.

Use the smallest set of scopes needed, keep credentials in a secret manager, rotate them after suspected exposure, and never place secret keys in browser code, prompts, repositories, or generated MCP configuration.

Messaging and broadcasts

A contact record or imported phone number is not permission to send. Broadcast eligibility requires active category-specific consent and no active global or category suppression. Wabery checks this when freezing the audience and again immediately before dispatch.

Mandatory opt-out keywords and common stop phrases cannot be disabled. Recording new consent does not silently lift a suppression; re-enrollment is a separate, audited action after new permission has been verified. Marketing frequency caps have platform-enforced defaults even when project settings are empty.

Broadcast delivery is deduplicated by message and recipient and paced per WhatsApp channel. An ambiguous provider acceptance is not automatically retried because avoiding duplicate customer messages is safer than guessing.

Contact data and imports

CSV requests, files, rows, columns, cells, metadata mappings, and concurrent imports are bounded. Import names and metadata are stored on the tenant-owned customer contact, not the globally shared phone identity. Contact erasure removes project data, broadcast personalization, flow dispatch/submission records, linked flow-event details, and connector invocation payloads before a shared phone identity is deleted.

Hosted functions

Only the active hosted-function deployment can run. Requests, results, logs, subrequests, CPU, and wall-clock execution are bounded. Secrets you add are available only to that function. Send them only to HTTPS endpoints you trust, and never print them in function logs.

Secure your production integration

These controls belong in your application:

• keep each wab_live_ API key in a server-side secret manager and grant only the scopes that application needs;
• verify x-wabery-signature over the exact raw webhook body before parsing it;
• keep webhook signing secrets, SIP credentials, payment credentials, and third-party function secrets out of browser code and agent prompts;
• use encrypted connections and least-privilege credentials for databases, queues, storage, email, payment, and voice services you connect to Wabery;
• rotate a credential immediately after suspected exposure; and
• avoid logging raw webhook bodies when they contain customer messages or personal data.

Platform security controls are included with Wabery and require no customer setup.

Wabery logs structured identifiers needed for operations while redacting authorization headers, tokens, secrets, customer phone/recipient fields, and connection URLs. Do not add raw request bodies or provider credential objects to application logs.

Report a suspected vulnerability privately to the Wabery security contact before public disclosure. Include the affected endpoint, reproducible steps, impact, and any request or correlation identifiers that do not contain customer data or secrets.