Skip to content

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_at takes an ISO 8601 time only, not natural language such as “in 1 hour”.
  • Attachments take base64 content only; fetching a remote path is not supported.
  • Validation errors are 422 validation_error, and an unverified sending domain is 403 domain_not_verified.
  • Lists with many results use limit with after (emails, logs) or page with limit (contacts, suppressions); there is no before.
  • 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.