Security / TOMs

Dualhook applies practical security controls appropriate for a small self-serve SaaS. Measures are reviewed as the service evolves and may be updated if the overall level of protection is not materially reduced.

Dualhook does not currently publish independent security attestations, a formal uptime SLA, or a commitment that all processing stays in one country or region.

• Authentication is handled through Clerk.
• Dashboard access is scoped to the user's authenticated organization.
• Organization-scoped records are queried and updated with organization identifiers.
• Meta access tokens are never returned through customer-facing pages or APIs.
• Connection-scoped dh_live_ runtime keys are displayed once, stored only as SHA-256 hashes, and can be rotated or revoked by organization admins.

• Production traffic is served over HTTPS/TLS through the hosting platform.
• Connection secrets such as Meta access tokens and webhook verify tokens are encrypted at the application layer using AES-256-GCM with a master key from environment configuration.
• The Cloudflare runtime decrypts a Meta token only for the duration of an authenticated, allowlisted operation and adds appsecret_proof where supported.
• Support attachments are stored as private Vercel Blob objects and are served through authenticated access checks.

Dualhook is designed around direct webhook routing. In the standard Webhook Override flow, message-path traffic is routed from Meta to the customer endpoint configured in Dualhook. Dualhook stores operational metadata needed for setup, monitoring, support, billing, security, and auditability.

Outbound message payloads and requested media stream through the Dualhook runtime without persistence or caching. Runtime logs exclude content, recipient numbers, authorization headers, and Meta download URLs.

Webhook logs and health checks can be retained for 7, 30, or 90 days according to the organization's Compliance settings. Support attachment blobs are deleted 7 days after ticket closure.

• Webhook endpoint validation rejects unsafe local, private, loopback, link-local, metadata, documentation, and otherwise non-public targets where the validation path applies.
• Authenticated API endpoints use scoped rate limits.
• The outbound runtime exposes only exact message and media routes, binds each key to one connection, rejects arbitrary Graph API paths, and never retries sends automatically.
• Customer webhook delivery includes trace IDs and delivery status metadata for troubleshooting.
• Operational email delivery uses idempotency keys for duplicate-prone lifecycle and alert sends.

• Webhook delivery metadata, health-check snapshots, connection alerts, API-key lifecycle events, email delivery logs, and support tickets are logged for operational purposes.
• Admin and support workflows use organization and ticket scoping.
• Errors and abuse signals are recorded for troubleshooting, fraud prevention, and service protection.
• Logs are intended for operational metadata and should not be used by customers as a message-content storage system.

Dualhook uses subprocessors for authentication, hosting, database, email, analytics, storage, and billing as listed on the Subprocessors page. Subprocessor terms and provider controls supplement Dualhook's own measures.

If Dualhook becomes aware of a personal data breach affecting customer personal data processed under the DPA, Dualhook will notify affected customers without undue delay and provide information reasonably available at the time.

Suspected security issues can be reported to contact@dualhook.com.

• Use strong authentication practices for your users and remove access that is no longer needed.
• Protect Dualhook runtime keys, webhook endpoints, verify tokens, any customer-owned Meta credentials, and downstream systems.
• Configure retention, exports, and downstream tooling to match your own legal and security obligations.
• Review Meta / WhatsApp policy requirements, end-user notices, opt-ins, and lawful basis for your messaging use cases.