Look up a send request
Idempotency, limits and retries are covered once, in the Send API guide.
Resolves a request_id returned by POST /v1/send — from either a
200 or a 202 — to what became of it: sent with the SES
message_id, in_flight at the origin, or failed with the reason.
It returns status only, never the message's recipients or content.
The request must be looked up with a key of the same environment
(sk_live_ / sk_test_) that sent it.
A request the edge queued (202) is 404 until SendOps takes it off
the queue, and the lookup is 503 while the origin is down; see
"Looking up a queued request" in the API description.
A request_id is only visible to the organization that made the
request; any other organization gets 404.
Path parameters
request_id string required The request_id from the send response. An opaque string.
Responses
Errors follow the RFC 7807 problem format — see the error reference.
request_id string required status string enum required sent: SES accepted it. in_flight: the origin is sending it, or
the last attempt ended without SES confirming either way — retry
the send with the same Idempotency-Key. failed: refused, see
error. There is no queued here: a request the edge still holds
is 404 until SendOps takes it off the queue.
One of: sent, in_flight, failed
message_id string optional The SES message id. Present when status is sent.
error object optional Present when status is failed.
Fields of error:
code string required The Problem code the send would have been answered with. A
request the edge queued can also fail with key_revoked (the
key was revoked, or expired past its rotation grace, before the
request was sent), payload_missing (the stored request was
lost before it could be sent) or retries_exhausted (it could
not be sent before its retries ran out). For the last two, send
it again with a new Idempotency-Key.
detail string required code: invalid_key); or a rotated key past its 24-hour grace window (code: key_expired). Carries a WWW-Authenticate: Bearer challenge. The edge answers the same codes itself, with X-SendOps-Path: fallback, when it checks the key before queueing a send. A revoked key is invalid_key; key_revoked is never an HTTP response, only a lookup's error.code. application/problem+json api.send scope (code: invalid_scope), or the request did not come through the edge at ingest.sendops.dev (code: edge_required). application/problem+json code: rate_limited). Retry after Retry-After. application/problem+json code: internal_error). Quote request_id to support. application/problem+json code: overloaded with
X-SendOps-Shed: 1 when SendOps is shedding load;
code: upstream_unavailable when the organization's AWS SES throttled,
is out of daily quota, could not be reached, or failed without
confirming the send (never with X-SendOps-Shed). The edge also
answers upstream_unavailable with Retry-After: 2 and
X-SendOps-Path: fallback when it cannot reach the SendOps origin,
the origin times out, or recent failures have it skipping the origin
for a few seconds; and with X-SendOps-Path: direct plus
X-SendOps-Reason: unreplayable when the origin failed after a body
over 10 MB was already streamed to it. Both codes are retryable after
Retry-After, with the same Idempotency-Key. A definite SES
refusal of the message (MessageRejected, sending paused, unverified
MAIL FROM) is a 400 validation_failed with SES's reason instead.
application/problem+json