Saltar al contenido principal

List Subscription Deliveries

GET 
/v1/subscriptions/:subscription_id/deliveries

Every export this subscription has sent, newest first. Did the mail land?

POST /v1/subscriptions/{id}/test answers dispatched: true, delivered: null and says, correctly, that "the outcome of a test is the mail itself — ask the recipient". It says that because the request cannot see the render finish, not because the outcome is unknowable: the delivery half writes it onto the same row minutes later. This is where it lands.

lastRun / lastStatus on the subscription itself report SCHEDULED runs only and are the right fields for "is my schedule healthy". They are one scalar each and they are overwritten every week. This is the log: one row per send, kept, with the per-recipient outcome on it.

trigger separates the two without either having to lie — schedule when a Task row drove it, manual for the on-demand test, which deliberately persists no Task so it cannot leave a phantom schedule behind.

status has seven values and only two of them are good news; see GET /v1/alerts/{alert_id}/deliveries for what each means. The one to read carefully is not_recorded: the capture settled and no delivery outcome was ever written, so the product cannot say whether anything was sent. That is not a failure, and reporting it as one would be the same overstatement this whole surface exists to avoid.

Access is the subscription's dashboard, and — as for GET and DELETE — it still answers once that dashboard is gone: what was delivered is history.

Cursor-paginated. The wire query parameter is exclusiveStartKey (what the cURL tab and the parameter table show); the TypeScript SDK takes it as the exclusiveStartKey option and the Python SDK as the exclusive_start_key keyword — one parameter, spelled per language. Pass the previous page's nextKey and stop when it comes back null — or let iterAll() / iter_all() drive the cursor for you (see the SDKs page, "Pagination").

Request​

Responses​

Successful Response