List your verified sender addresses
The claims belonging to the PERSON this credential authenticates as, in this org — verified and pending both, because a pending claim is the answer to "did my code arrive".
Requires a user-delegated token. A claim is one person's proof that
they can read one mailbox, so a client-credentials token — which
identifies nobody — is refused with 422 rather than being answered
with an empty list that would read as "you have verified nothing".
Never returns a verification code.
Responses
Errors follow the RFC 7807 problem format — see the error reference.
data array<object> required Each entry in data:
id string<uuid> required email string required The address, lower-cased. PII.
status string enum required locked means five wrong codes; the way out is a fresh POST /v1/verified-senders, not a sixth guess.
One of: pending, locked, verified
code_expires_at string<date-time> optional When the outstanding code lapses, 15 minutes after it was sent. Absent on a verified claim — confirming clears the code.
verified_at string<date-time> optional Present once the code came back. This is what the mint path asks about.
created_at string<date-time> required pagination object required Fields of pagination:
has_more boolean required next_cursor string | null optional validation_failed Problem. When the refusal is about a
reference — a segment key, template slug, topic or attribute name the
organization does not have — it additionally carries validation_code,
field, line/column, missing, candidates and next_step, so a
client can correct the call without a second round of guessing. See
ValidationProblem.
application/problem+json code is internal_error. The
request_id field can be quoted to SendOps support to investigate.
application/problem+json