Test Resend webhook reconciliation before production

I was trying the Resend API for a small product flow, and the first POST /emails call was not the part that worried me most.

That call gives you an email ID.

The part I care about is what happens later, when events come back:

email.delivered
email.bounced
email.opened

Resend has docs for these webhook events:

• email.delivered: https://resend.com/docs/webhooks/emails/delivered
• email.bounced: https://resend.com/docs/webhooks/emails/bounced
• email.opened: https://resend.com/docs/webhooks/emails/opened

The docs are useful. But the integration question is not just "what fields are in the payload?"

The real question is:

can my app map this event back to the right email record?

The small bug that becomes annoying later

Most apps do something like this when sending email:

create internal notification record
send email with Resend
store resend email id
wait for webhook events
update notification status

Simple enough.

But the webhook arrives later, outside the request that sent the email.

So now your app needs to answer a few things correctly:

• which internal record owns this Resend email ID?
• should email.opened change the same status as email.delivered?
• what happens if email.bounced arrives after you already marked the email as sent?
• do you store the raw event payload for debugging?
• can you replay the event without creating duplicate state changes?

None of this is hard in theory.

It is just easy to skip until production.

Testing only the send call is not enough

If you test only this:

POST /emails

you have proven that Resend accepted the request.

You have not proven your app can handle the lifecycle around that request.

For a real product, I want to test this chain:

send email
store provider email id
receive delivered event
update internal status
receive opened or bounced event
reconcile final state

That is the integration.

The endpoint is just one step inside it.

Why this is awkward to test early

To test this against the real provider path, you usually need:

Resend API key
verified sender domain
public webhook endpoint
local tunnel
event logging
test recipient
some app state to update

That setup is reasonable before production.

But when I am still exploring the API, I do not want to create all of that just to understand whether the workflow makes sense.

I want to run the shape of the workflow first.

The workflow I wanted from my IDE

At that point I wanted Cursor or Claude to run a small workflow for me:

send test email
capture email id
simulate delivered event
simulate opened or bounced event
verify app-facing state
show what changed

I tried this through FetchSandbox MCP because it gives the agent a runnable API workflow instead of only docs to read.

This is not replacing Resend's real environment. I would still need the real API key, real domain, production webhook endpoint, and provider limits before shipping.

The point is earlier than that.

Before wiring the real app, I wanted the agent to understand the lifecycle:

request -> provider id -> webhook event -> internal state

What made the validation useful

What helped was not a fake "success" message.

It was seeing a small report closer to:

PASS POST /emails returned email id
PASS internal record stored provider id
PASS email.delivered event matched provider id
PASS notification status changed to delivered
PASS email.opened event was recorded without duplicating the send

Or if it fails:

FAIL webhook event could not be matched to an internal record

That is the kind of failure I would rather see before production, not after users are asking why they never got an email.

Try the workflow

If you are exploring Resend, this is the workflow page I used:

https://fetchsandbox.com/docs/resend

From an MCP client like Cursor or Claude, the ask is simple:

validate resend email workflow with fetchsandbox

The workflow should not stop at POST /emails -> 200.

It should prove the lifecycle after the send call makes sense.

That is where most integration bugs hide.