Resend sandbox for email API and webhook testing
A stateful Resend sandbox with all 83 endpoints, 9 pre-seeded resource types, idempotent email sends, and webhook events on every email lifecycle change. Test your transactional email integration without sending real emails, burning your quota, or worrying about your coworkers' inboxes.
Test Scenarios
Run real email lifecycle events and handler tests without sending a single real email.
Send Email
POST /emails returns a queued email ID, fires email.sent
Email Delivered
Simulates email.delivered webhook on the queued email
Bounced Email
email.bounced event with hard/soft bounce category
Domain Verification
Add domain → trigger DNS verification → verified state
Audience + Contacts
Create audience, add contacts, list subscribers
Broadcast Send
Schedule broadcast to audience, fire delivered events
API Key Lifecycle
Create, list, revoke API keys for permission testing
Idempotency
Replay POST /emails with the same key returns the original
Webhook Replay
Re-deliver any email/contact/domain event for handler tests
Pre-seeded Resources
Every Resend sandbox starts with realistic data across all 9 resource types.
How It Works
- 1
Open the portal
A stateful Resend environment is provisioned in under 2 seconds — no signup, no real domain verification.
- 2
Point your app at the sandbox URL
Replace api.resend.com with the sandbox base URL. Use the sandbox bearer token in place of your RESEND_API_KEY.
- 3
Send emails
Every POST /emails returns a queued email ID and fires email.sent. State persists — GET the email back to check status.
- 4
Test webhook handlers
Replay email.sent, .delivered, .bounced, .opened, .clicked into your handler to verify signature checks, idempotency, and bounce handling.
Why a Resend sandbox?
Resend's API is one of the cleanest in the industry, but testing against it sends real email. Real domain verification. Real quota burn. Real risk of accidentally spamming your team while iterating on a templating bug. Even Resend's test mode still creates real records on their servers.
FetchSandbox runs a fully stateful Resend mock from Resend's public OpenAPI spec. All 83 endpoints. The full email lifecycle. Webhook events on every state change. No real email delivery, no quota, no risk.
Use real Resend in production. Use FetchSandbox for development, CI integration tests, webhook handler debugging, and onboarding engineers without giving them production keys.
What you can test in the Resend sandbox
Use FetchSandbox when you need more than a static mock response. A POST to/emailsreturns a real sandbox email ID, stores the message, supports idempotency replays, and lets your app read the email back later. Webhook tests can then replayemail.sent,email.delivered,email.bounced, and complaint events against the same state your integration already created.
FAQ
Do real emails get sent?
No. FetchSandbox runs a fully stateful Resend sandbox. No real email delivery, no SMTP, no quota burn.
Is this a mock Resend API?
Yes, but it is stateful rather than a static mock. Sends create email records, idempotency keys return the original response, and lifecycle webhooks can be replayed against the same sandbox data.
Does it support audiences and broadcasts?
Yes. Create audiences, add contacts, schedule broadcasts. State persists across calls so list endpoints reflect prior mutations.
Can I test my webhook handler?
Yes. email.sent, .delivered, .bounced, .opened, .clicked, and .complained events fire on lifecycle changes and can be replayed against your handler for signature and idempotency tests.
What about domain verification?
The sandbox simulates the verification flow — POST /domains creates a pending domain, POST /domains/{id}/verify transitions it to verified. No real DNS checks.
Can I use this in CI?
Yes. Spin up a sandbox via the API, run your tests against it, tear it down. No quota concerns, no shared state across CI runs.
Related reads
Ready to test your Resend integration?
Free tier — 3 sandboxes, 10,000 requests/month. No credit card required.
Open Resend Portal