Resend
Connect your verified domain to send waitlist email.
Resend connects a verified sender to Waitlyze. Manage a shared workspace connection in Settings → Integrations, or give one waitlist its own sending identity in Waitlist settings → Sender identity.
Connect your sender
Verify your domain and create a key
In Resend, add and verify your sending domain, then create a sending-only API key. See Resend domain setup.
Connect in Waitlyze
Go to Settings → Integrations → Resend → Connect. This needs owner/admin permission. Enter the key and a sender email on your verified domain, then Save. The key is encrypted and never returned to the browser - enter a replacement to change it.
Add the Resend event webhook
After saving, copy the webhook URL shown in the connection panel. Add it in Resend and subscribe to email.bounced and email.complained. Copy the signing secret Resend creates, return to Waitlyze, save it, then send a test email. The test goes to your Waitlyze account email.
The connection is ready only after the test succeeds. Subscriber email is sent only through a connected waitlist or workspace sender; Waitlyze never falls back to its deployment Resend key for customer mail. If a published form requires email confirmation, connect and test a sender before publishing. Keep the Resend event webhook configured so permanent bounces and complaints can update the workspace suppression list.
If a test fails
- Confirm the key is sending-only with send permission, not a full-access or expired key.
- Confirm the sender address domain matches a verified Resend domain exactly.
- Confirm the webhook signing secret is saved; the test action stays disabled until it is configured.
- Correct the details, save, and test again.
- Check Email tools delivery health for dispatcher versus sender errors.
Disconnecting stops subscriber email delivery until a connected waitlist or workspace sender is available. Waitlyze's deployment sender remains reserved for product emails to workspace owners, such as account notices and invitations.
List your Resend domains
GET /api/settings/integrations/resend/domains returns the domains on your connected Resend account (id, name, status, createdAt) so you can confirm a domain is verified before using it as a sender. It reads the stored key in memory only - the key is never logged or returned.
Per-waitlist sender identity
Each waitlist can store its own Resend key and From address instead of inheriting the workspace connection. Owners and admins can open Waitlist settings → Sender identity, enter a sending-only key and verified From address, save, and send a real test email to their account address. The page shows the active source and address, override status, last test time, and error code. Change the key by entering a replacement; a blank key keeps the saved encrypted key. Remove the override to return to the inherited sender. These actions also use session-protected routes (GET / PUT / DELETE /api/wait-lists/[id]/email-sender, POST /api/wait-lists/[id]/email-sender/test), not public API-key endpoints.
- Resolution order is connected waitlist sender → connected workspace sender. There is no deployment-sender fallback for subscriber mail. A waitlist sender in
NEEDS_TESTstays dormant and may use the connected workspace sender; if neither is connected, customer sends are blocked.GETreports the resolved source and From address without exposing credentials. - Save-and-test-to-activate, same as the workspace flow: the sender stays dormant until a test email succeeds, and deleting it falls back only to the connected workspace sender.
- Fail-closed: a configured sender that breaks (bad key, undecryptable secret) surfaces a founder-facing error instead of silently reverting to the platform sender.
The waitlist override is used for verification, broadcast, automation, offboarding, direct welcome, and template/broadcast/automation test sends. Founder account notices remain on the platform sender. The workspace Resend webhook is still the configured path for bounce/complaint suppression; waitlist-level keys do not create a separate callback or signing-secret slot. If you use a waitlist-level Resend account, configure its bounce/complaint events to reach the workspace webhook so suppression stays current.
Bounces, complaints, and suppression
Signed email.bounced and email.complained events delivered to the workspace Resend webhook update workspace suppression with recipient evidence. Bounced or complained addresses are excluded from future broadcasts and automations, including early webhook races where the complaint arrives before the send completes. This is automatic - you do not manage the suppression list by hand.