Security model
Wabery treats every API key, OAuth grant, project, channel, contact, and real-time subscription as tenant-scoped. Authentication proves identity; route-level scope checks and database ownership filters decide which project resources that identity may use.
Credentials and authorization
Section titled “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 cannot be replayed directly against the REST API. The MCP service supplies a separate server-to-server proof.
- High-risk hosted MCP tools require person-controlled client elicitation. Trusted local stdio MCP uses explicit write mode and confirmation tokens.
- WebSocket subscriptions first validate organization and conversation ownership, then listen only on organization-specific channels.
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
Section titled “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 work is claimed atomically, deduplicated by message and recipient, bounded per WhatsApp channel, and capped across the worker pool. An ambiguous provider acceptance is not automatically retried because avoiding duplicate customer messages is safer than guessing.
Contact data and imports
Section titled “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
Section titled “Hosted functions”Function tokens have a dedicated issuer and audience and are bound to the exact active deployment version. Activating a new version invalidates the previous deployment’s token. Internal payloads, logs, results, upstream responses, subrequests, CPU, and wall-clock execution are bounded.
Production requires unique values for WABERY_FN_TOKEN_SECRET,
WABERY_FNS_DISPATCH_SECRET, and WABERY_FNS_INVOKE_SECRET. User function
secrets are available only to that function; user code should still send them
only to trusted HTTPS endpoints.
Required production controls
Section titled “Required production controls”Configure:
CHANNEL_ENCRYPTION_KEYfor stored channel credentials;WHATSAPP_REGISTRATION_PINas a non-default six-digit fallback for legacy channels (new onboarding stores a random encrypted PIN per number);MCP_OAUTH_SIGNING_SECRETas a dedicated random secret of at least 32 characters. Never reuseBETTER_AUTH_SECRET;MCP_INTERNAL_SHARED_SECRETidentically on the web API and hosted MCP service;- webhook verification and signing secrets;
- TLS Redis (
rediss://) and database connections on private networks; and - separate least-privilege Cloudflare, Meta, storage, email, and payment credentials per environment.
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.