Revoke a per-entity address
Retires the address. 204 whether or not it was there: revoking twice is ordinary, and a 404 on the second call would have every idempotent client special-case a state that means the same thing.
What revocation stops, precisely. The metadata: the address leaves
the published routing, so deliveries stop carrying its entities entry.
Delivery itself stops only on a domain with a non-empty
allow_patterns, because that list is the only thing that ever refuses
a recipient — and not even then when removing the entry would leave the
list EMPTY, since an empty allow-list means "deliver every recipient"
and emptying it while taking one address away would open the whole
domain. In that one case the pattern is kept and the address is still
revoked. To stop delivery to a local part outright, edit
allow_patterns through PUT /v1/inbound/domains/{domain}/webhook,
where you can see what the list will become.
The local part MAY be allocated again afterwards, unlike a DMARC reporting address: it is your own choice at your own domain, and a reopened ticket must be able to have its address back. Which is why this is not classified destructive. The metadata is not restored — supply it again.
Path parameters
domain string required The receiving domain, by NAME (in.acme.com). A UUID is also accepted. Matched case-insensitively, and scoped to the calling org — a domain belonging to another org is a 404, never a 403.
localPart string required The part before the "@" of a per-entity address — ticket-4231. The whole address at this domain is accepted too and is trimmed to its local part; an address at a DIFFERENT domain is not, and reads as "no such address here" rather than being silently trimmed.
Responses
Errors follow the RFC 7807 problem format — see the error reference.
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 code is internal_error. The
request_id field can be quoted to SendOps support to investigate.
application/problem+json