Control 01
Consent and identity
Double opt-in, signed unsubscribe links, deduplication, and explicit verification state keep the audience record explainable.
Security
The waitlist stays explainable at every handoff.
Public capture, operator access, and automation stay in separate trust boundaries. Consent, signatures, and delivery history stay visible.
What a receiving system can check
- The person confirmed their own email
- The signature matches the body
- The timestamp is inside the window
- The row carries its own workspace key
HMAC SHA-256 over timestamp + body
- Audience identity
- Signed consent state
- API boundary
- Scoped + expiring
- Webhook signing
- HMAC SHA-256
Checks passed
A trust boundary should be visible.
WaitForge separates public capture, authenticated control, and machine delivery. Each boundary has its own evidence, instead of asking one shared secret to protect the whole launch.
- Capture
- Bounded + rate limited
- Operator access
- Authenticated
- Delivery proof
- Signed receipt
- Sensitive state
- Server-side only
Security designed into the campaign lifecycle.
These are product controls, not decorative compliance claims. Each one corresponds to a state you can inspect or test.
Control 02
Scoped API access
Management requests use authenticated, expiring, least-privilege tokens bound to one Pro board or Business workspace.
Control 03
Signed delivery
Webhook bodies include a timestamp and HMAC SHA-256 signature so your receiver can authenticate the exact payload.
Control 04
Recovery controls
Delivery history, bounded retries, replay, and staged secret rotation reduce operational risk without disabling the endpoint.
Webhook receipt
Verify the bytes you received.
Compare the signed timestamp and raw body with a constant-time HMAC check. Reject stale timestamps before doing any work.
const signed = timestamp + '.' + rawBody
const expected = hmacSha256(secret, signed)
if (!timingSafeEqual(signature, expected)) {
return new Response('Invalid signature', { status: 401 })
}Workspace isolation
One database, separated row by row — and audited on every release.
Every workspace-owned record carries its workspace key on the row itself, filtered by a scope the ORM applies rather than by queries remembering to. Two auditors run in CI and fail the build if any table is missing that key, or if any page returns another workspace’s data.
This is not per-customer database isolation, and there are no per-tenant encryption keys. The full statement says what is checked, what is not claimed, and which gaps are still recorded as debt.
Field notes
Security questions, plainly answered.
Does the embed expose a secret?
No. The embed receives only public presentation and field configuration. API tokens and webhook secrets remain on trusted servers.
How should webhook signatures be verified?
Use the raw request body, signed timestamp, endpoint secret, and a constant-time comparison. Reject timestamps outside your replay window.
Can webhook secrets rotate without downtime?
Yes. Staged rotation lets the previous and next secret overlap while receivers deploy the change, then commits the next secret.
Does WaitForge claim formal certification?
This page documents implemented product controls. It does not imply a certification or audit that has not been completed.
Build an email campaign your systems can trust.
Start with hosted capture, then enable only the released identity and automation controls your launch needs.