Resend
What is HardGraph? HardGraph publishes curated, provenance-backed agent skills grounded in reproducible vendor documentation.
Resend is an email API built around a single primitive — sending — with a REST API, SDKs per language, and React Email for templating. It is not an SMTP replacement you drop in blindly: the parts that determine whether mail actually lands are outside the API call itself.
The decision that shapes everything else
Before any code runs, ownership of the sending domain must be established: Resend requires adding
DNS records (SPF, DKIM, and typically a return-path/tracking record) to a domain the sender
controls, and verification is asynchronous — it does not complete the moment records are added.
Sending from an unverified domain, or from onboarding@resend.dev, works for testing but is a
different reputation path than production mail; do not treat the test sender as a preview of
production deliverability. Domain verification, not the API key, is the actual gate on whether
recipients see the message land in an inbox versus spam or nowhere.
Products that get confused
- Emails API is transactional: one send call, one recipient set, triggered by application events (receipts, password resets, notifications). This is what "Resend" usually means.
- Broadcasts and Audiences are marketing sending: managed contact lists, unsubscribe handling, and campaign-style sends. Mixing transactional traffic into a broadcast-sending domain or IP path degrades deliverability for both — they are reputation-isolated for a reason, and picking the wrong one because "it's all just Resend" is the most common integration mistake.
- React Email is a templating library that renders to HTML; it is maintained by the same team but is usable without Resend as the sender, and using Resend does not require it.
What surprises people
Webhook payloads (delivery, bounce, complaint, open, click) must be verified against Resend's signature before being trusted — an unverified endpoint is a forgeable event source, and bounce or complaint webhooks are the only reliable signal that a domain's reputation is degrading, so polling send status is not a substitute for subscribing to them. Idempotency keys prevent duplicate sends on retry; omitting one on a retried request path can double-send transactional email silently.
What to verify rather than recall
Rate limits, the exact webhook event-type list, per-plan sending volume, supported SDK languages,
and API endpoint paths all change between releases. Confirm these against the mirrored corpus under
references/vendor/ or the live docs rather than asserting a remembered number — a stale rate limit
or event name fails silently rather than raising an error.