API keys
Create, store, replace, and revoke per-waitlist signup keys.
API keys live in Settings → Integrations → API keys. Workspace owners and admins can create keys for waitlists they manage. Members cannot. The API reference lists the public endpoints these keys can use.
Create and store a key
Open API keys
Go to Settings → Integrations → API keys. The legacy /api-keys URL redirects to this section.
Choose a waitlist and expiry
Name the key and select its waitlist. Choose expiry of 30 days, 90 days, one year, or never. Each waitlist has one active key at a time.
Save the secret once
Reveal or copy the key before closing the panel. Store it in a server variable such as WAITLYZE_API_KEY. Waitlyze stores only its hash and cannot show the plaintext again.
Test a signup
Send a test Signup API request with the new key and matching waitlistId. Confirm 200 before wiring production traffic.
Replace or revoke a key
Revoke the old key
Revoke, then confirm you understand access loss. Revocation takes effect immediately - in-flight requests with the old key start failing with 401.
Create its replacement
Create the new key for the same waitlist, copy it, and update your server configuration.
Verify and monitor
Send another test signup. Watch for 401 (missed rotation) versus 409/429 (app-level, not key) in Troubleshooting.
Plan for the replacement window
With one active key per waitlist, revoke → create briefly interrupts integrations. Rotate during low traffic. There is no overlapping-key rotation or automatic default workspace key.
Scope and access
API keys work on all plans, including free - there is no plan gate on creating, listing, or using keys. Every key carries the same scopes and the same per-key rate limit below regardless of plan.
The UI creates waitlist:write keys scoped to the selected waitlist. They can create signups, look up signup status, and award configured custom points. They cannot list subscribers, change pages, manage workspaces, or call dashboard-only /api/v1 routes.
| Allowed | Denied |
|---|---|
POST /api/waitlist for the linked waitlistId | Listing subscribers or exports |
GET /api/waitlist status lookup (position, referral link) | Managing keys, pages, workspace, email, domains, webhooks |
POST /api/waitlist/points for a verified signup on the linked waitlist | Accessing any other waitlist |
Passing referralCode / referral_code for the same waitlist | |
Idempotency-Key replays of your own signups | Reusing one key across different emails (409) |
Expired or revoked keys return 401. A mismatched waitlistId (key for A, body says B) also returns 401.
Each key gets 5,000 requests per day across signups, status lookups, and point awards (all three endpoints share the same budget), reported via X-RateLimit-Limit / X-RateLimit-Remaining / X-RateLimit-Reset. Prefer header auth (x-api-key or Authorization: Bearer) for GET lookups so the secret never lands in URLs or logs.