List an inbox's pull URLs
Which pull URLs exist on this inbox, live ones first, then revoked ones with the time each was cut off.
No URL and no token value in any row. Only hashes are stored, so there is nothing to return — this is the metadata you revoke by, not a way to recover a link. Reading this list gives nobody access they did not already have.
Unpaginated, in the standard {data, pagination} envelope.
pagination.has_more is always false: ten live tokens is the
ceiling, and the revoked ones are deleted with the inbox.
Path parameters
id string<uuid> required The inbox's UUID, exactly as returned by POST /v1/inboxes. A value that is not a UUID is a 404 rather than a 422 — it names nothing, and saying "that is not a valid UUID" would confirm the format of ids that do exist.
Responses
Errors follow the RFC 7807 problem format — see the error reference.
data array<object> required Live tokens first, then revoked ones, each newest first.
Each entry in data:
id string<uuid> required What you revoke by. Pass it as token_id to DELETE /v1/inboxes/{id}/pull-tokens/{token_id}.
prefix string required The first characters of the token body, display only. Safe in a log line, a dashboard column or a screenshot, which is the whole reason it exists — it identifies a URL without being one.
label string required Your note, for telling several URLs on one inbox apart. Matched against nothing. Not a place for your user's email — that is what account_ref is for.
Constraints: length 0–80
created_at string<date-time> required revoked_at string<date-time> | null required Null while the URL still opens the inbox. A timestamp rather than a boolean because "when was this URL cut off" is the question an incident asks.
pagination object required Fields of pagination:
has_more boolean required next_cursor string | null optional code is internal_error. The
request_id field can be quoted to SendOps support to investigate.
application/problem+json