Trace a missing Resend email from your logs to the API request log

Last verified on Nov 8, 2026.

An email that never arrives leaves two partial records. Your service logged that it asked an email provider to send. The provider has its own record of what it received and what happened next. Resend keeps both its API request logs and its per-email records, and its MCP server exposes them, so the Sazabi agent can follow a message across the boundary instead of you doing it by hand in two tabs.

What the Sazabi agent can do with Resend

Sazabi connects to Resend's hosted server at mcp.resend.com/mcp. There is no OAuth step. You paste a Resend API key, Sazabi stores it, and the agent calls the server with it. Resend's tool reference groups what is available by resource:

• Emails: send, list, get, cancel, update and batch send. List and get are how the agent reads what happened to a particular message.
• Received Emails: read inbound email and its attachments.
• Logs: list and inspect API request logs, including the full request and response bodies.
• Domains: list, get and verify sender domains, with tracking and TLS settings.
• Webhooks: list and get the webhooks configured for event notifications.
• Contacts, Segments and Broadcasts: audience and campaign management.

The key sets the ceiling, and neither option is read-only. Sazabi's setup page says to choose between Sending access, which sends email only and is the safer choice, and Full access, which also manages domains, contacts and audiences. A Sending access key can't read anything back, so the investigation below, which reads request logs, email records and domains, needs Full access. Since both keys can send, tell the agent in your prompt that this is a diagnostic task and not to send anything. Sazabi shows every tool call the agent makes, so you can see what it ran.

Questions it answers

• Did our request to Resend succeed, and what did the response body say?
• Which email did that API call create, and what is its current state?
• Is the sending domain verified, or did a DNS change break it?
• Which webhook endpoints are set up for delivery events?
• Did the same request go out twice because of a retry?

A worked example: a password reset that never arrived

A customer on example.com says their reset link never came. Your logs show POST /auth/reset returning 200 with a request ID. In the thread you ask:

The reset request from user 8841 at 09:12 UTC returned 200 in our logs. Look
in the Resend API request logs around that time. Was the call accepted, what
email did it create, and what state is that email in?

The agent first finds the request in your logs and notes the time window and the sender address. It then reads the Resend Logs for that window and filters to the send endpoint. Resend's log detail records the status code and the request and response bodies, and it links a log to the email records that the request created. The agent follows that link to the email and reads its state with the Emails tools.

That one chain tells you where to look next. A 4xx response in Resend's logs means your service sent something Resend rejected, such as a sender on an unverified domain, and the 200 in your own logs was your own wrapper swallowing the error. No log at all means the request never reached Resend, which puts the failure inside your service. A log with a 200 and a created email means Resend accepted it, and the state of that email is the lead. If it looks like a domain problem, ask the agent to list the domain and check its verification status. Resend's docs note that you can send from any address on a verified domain, so a sudden failure on a sender that used to work usually points at the domain, not the address.

How it fits with other integrations

If the failing service runs on a cloud platform, the agent can read its logs from Vercel or AWS alongside the Resend records. Raise the follow-up in Linear. The cloud platforms category covers where such a service runs, and the integrations index lists every tool the agent can reach. Plans are on the pricing page.