Security and compliance
Use workspace isolation, key rotation, audit logs, blocked recipients, and SSO safely.
Workspace isolation
Most resources belong to one workspace. API clients, senders, messages, webhooks, contacts, templates, campaigns, automations, team members, and audit logs are scoped by workspace.
Do not pass workspace IDs from browser code as a security boundary. Server-side authorization and session context must decide which workspace is accessible.
Public customer integrations should be server-to-server. Do not enable browser CORS access to API-key send endpoints and do not place `was_...` keys in frontend bundles.
Secret storage examples
Store API keys and webhook secrets in backend environment variables or a secret manager. Never commit them to Git and never print them in logs.
HOOKMESSAGE_BASE_URL=https://api.hookmessage.com
HOOKMESSAGE_API_KEY=was_xxx
HOOKMESSAGE_OTP_KEY=was_otp_xxx
# Paid connected-sender mode only:
# HOOKMESSAGE_SENDER_ID=9f4b5d4c-0000-4000-9000-123456789abc
HOOKMESSAGE_WEBHOOK_SECRET=whsec_xxxDeployment environment examples
Configure the same values in each deployment target. Use separate keys per environment so staging cannot send through production numbers.
# Vercel
vercel env add HOOKMESSAGE_BASE_URL production
vercel env add HOOKMESSAGE_API_KEY production
# Paid connected-sender mode only:
# vercel env add HOOKMESSAGE_SENDER_ID production
# Docker
docker run --env-file .env your-app-image
# Laravel .env
HOOKMESSAGE_BASE_URL=https://api.hookmessage.com
HOOKMESSAGE_API_KEY=was_xxx
# Paid connected-sender mode only:
# HOOKMESSAGE_SENDER_ID=9f4b5d4c-0000-4000-9000-123456789abcOperational controls
Rotate API keys on exposure, revoke unused clients, limit sender assignments, and review audit logs for sensitive actions.
Use blocked recipients to prevent messages to protected numbers. Use SSO on eligible plans when centralized identity is required.
- GET /api/customer/security/audit-logs
- GET /api/customer/security/blocked
- POST /api/customer/security/blocked
- DELETE /api/customer/security/blocked/{phone_number}
- GET /api/customer/security/sso
- PUT /api/customer/security/sso
Logging and data handling
Treat API keys, webhook signing secrets, OTP codes, phone numbers, and message contents as sensitive operational data.
For debugging, log request IDs, `message_id`, `sender_id`, status codes, and error codes. Do not log raw API keys, webhook secrets, full OTP codes, or full message bodies.
- API key logging warning: if a key appears in logs, rotate it immediately.
- OTP logging warning: do not send OTP codes to analytics, browser logs, or support screenshots.
- Webhook logging warning: never log `HOOKMESSAGE_WEBHOOK_SECRET`; log only delivery ID and event type.
- CORS warning: public browser clients should call your backend, and your backend should call HookMessage.
Need help?
Use Book Integration Help if you want setup help for OTP or automated customer messaging.
Continue building
Next steps
Start here
A plain-language map of Free Sandbox, paid sender modes, credentials, and the first successful request.
Free Sandbox quickstart
The shortest beginner path from a verified account to a queued Free Sandbox OTP.
Glossary
Understand workspaces, keys, senders, receivers, queue states, webhooks, and idempotency.
Authentication and access
HookMessage separates customer API keys, dashboard sessions, and internal platform access.