contacts
Delete a contact
DELETE /v1/contacts/{email}
Auth required
api.contacts.manage
Archives the contact in SES (removes from the contact list). The
call is idempotent: deleting a contact that does not exist or is
already archived returns 204 with no error.
Supports the Idempotency-Key header.
Path parameters
email string<email> required Recipient address. Percent-encode @ as %40. Matched case-insensitively.
Responses
Errors follow the RFC 7807 problem format — see the error reference.
204 Contact deleted (or was already absent)
401 Missing, malformed, or unknown API key application/problem+json
403 Either the credential lacks the required scope (
code: invalid_scope), or it is bound to the test environment and this operation is irreversible (code: test_environment_forbidden). Branch on code: the first is fixed by granting the scope, the second only by using a live credential. See the "Live and test credentials" section of the API description. application/problem+json 429 Per-org rate limit exceeded application/problem+json
500 Unexpected server-side failure. The
code is internal_error. The
request_id field can be quoted to SendOps support to investigate.
application/problem+json 503 An upstream dependency — the AWS SES account connected to this org —
refused, throttled, or did not answer in time. The
code is
upstream_unavailable; the status is 503 when the call failed and
504 when it exceeded our deadline.
Retryable. Always accompanied by Retry-After. On a 504 the
outcome is genuinely unknown (the write may have reached SES), so
retries of a non-idempotent call should carry an Idempotency-Key.
The detail string is deliberately generic: the underlying AWS error
describes the customer's own account and is recorded in SendOps logs
against the request_id, not returned here.
application/problem+json 504 An upstream dependency — the AWS SES account connected to this org —
refused, throttled, or did not answer in time. The
code is
upstream_unavailable; the status is 503 when the call failed and
504 when it exceeded our deadline.
Retryable. Always accompanied by Retry-After. On a 504 the
outcome is genuinely unknown (the write may have reached SES), so
retries of a non-idempotent call should carry an Idempotency-Key.
The detail string is deliberately generic: the underlying AWS error
describes the customer's own account and is recorded in SendOps logs
against the request_id, not returned here.
application/problem+json