Skip to main content
GET
Get Email Send
You can retrieve a queued, sent, suppressed, or failed email by emailSendId. Email send rows are cleaned up after 14 days; when the row is gone, the API returns retained ClickHouse events and a sparse summary without emailBody. Test sends appear in sent-email history and are available through this exact-ID endpoint while their row is retained. Use status and errorMessage as the delivery contract. Queue jobs are an internal execution detail and are not exposed by this API. For an email that didn’t arrive, outcome says why and reason says it in one sentence, with the receiver’s status code when there is one:
  • bounced: the address can’t take mail, for example it doesn’t exist or the mailbox is full.
  • blocked: the receiver refused because of the sender: spam or content, the sending domain’s reputation, policy, or its SPF, DKIM or DMARC.
  • delayed: delivery is still being retried.
  • failed: we couldn’t deliver it. reason is always “We couldn’t deliver this email.”
Both are null for emails that arrived or haven’t finished. Event metadata shows the receiver’s reply with our servers masked for bounced and blocked emails, and the same generic sentence for failed ones. sendingIpAddress and observedSendingIpAddress are always null. status: "failed" is not a bounce. internalFailureCode is transport_exhausted when we couldn’t deliver the email, admin_bounce when the message was withdrawn before delivery, and crash_orphaned_claim when sending stopped before the message was confirmed as handed off. In every case the address is still valid, remains subscribed, is not added to the suppression list, and does not count toward your bounce rate. Only status: "bounced" means the receiver judged the mailbox or the sender. New failure codes can be added over time, so treat an unrecognized internalFailureCode as a generic failure. type identifies the send source (campaign, sequence, or transactional) for compatibility with analytics. emailType is the normalized delivery policy (marketing or transactional), and isTransactional is its stored snapshot. For example, a marketing message sent through send_email has type: "transactional", emailType: "marketing", and isTransactional: false. Timeline events expose the same policy as deliveryPolicy; their legacy emailType field remains the source category. For cleaned-up legacy sequence/API sends without a stored policy snapshot, emailType, isTransactional, and event deliveryPolicy are null rather than guessed. For multi-recipient transactional sends (multiple to addresses or any cc/bcc), additionalRecipients contains the full recipient lists as actually sent. It is null for single-recipient sends and for ClickHouse-only fallbacks. CC/BCC delivery records return isCopiedRecipient: true and identify the original delivery with primaryEmailSendId when it is still available. Their emailBody is null because content, opens, and clicks remain attached to the primary email send.

Request

string
required
Email send ID.

Responses