Documentation
Coming from Resend.
What carries over, and what to check before you switch.
Coming from Resend
The send API is deliberately close to Resend’s, so moving a send call is mostly renaming the client. These match: POST /emails and /emails/batch with from, to, cc, bcc, reply_to, subject, html, text, headers, tags ({ name, value }), attachments (content, filename, content_type, content_id) and scheduled_at and topic_id (sent under a topic: an address whose contact opted out is skipped, and one that is not a contact follows the topic’s default, judged per address in to, cc and bcc); GET, reschedule and cancel for a single email; creating and updating a webhook with endpoint and events (url is accepted as the same field, and status as enabled), with webhook objects returning endpoint and status too; the Idempotency-Key header; and the { statusCode, name, message } error shape. Webhooks are signed with the same Standard Webhooks scheme and also carry svix-* headers, so a verifier you already have keeps working with the new secret.
These differ, so check them before you switch:
scheduled_attakes an ISO 8601 time only, not natural language such as “in 1 hour”.- Attachments take base64
contentonly; fetching a remotepathis not supported. - Validation errors are
422 validation_error, and an unverified sending domain is403 domain_not_verified. - Lists with many results use
limitwithafter(emails, logs) orpagewithlimit(contacts, suppressions); there is nobefore. - Not available: inbound email, automations, and an SMTP relay.
- Verify your domain first: DNS records differ, and a domain verified with another provider is not verified here.