Delete an account's alternate contact
DELETE/accounts/:accountId/contacts/:type
Removes one of an AWS account's three alternate contacts, mapping onto the
AWS DeleteAlternateContact call.
The contact is removed at AWS and cannot be recovered from here. Prism
keeps no copy: read it with POST /accounts/{accountId}/contacts/get
first if you might want it back. Removing the billing contact means AWS
billing notices for the account go to the root email instead.
Returns 200 with an envelope, not 204, and sends no body content of its own.
This is the route DELETE .../contacts/primary falls into. No delete
route is registered for primary, so that request arrives here with
type set to primary and is forwarded upstream, where it fails as a
502. There is no operation that deletes the primary contact; it can only
be replaced, through
PUT /accounts/{accountId}/contacts/primary.
Like the other five contacts operations, this one is a proxy to
CloudKeeper's ops-service, is present on every deployment, and reports
every upstream failure as a 502; see
POST /accounts/{accountId}/contacts/get for the full explanation.
Request
Responses
- 200
- 401
- 403
- 404
- 502
The ops-service accepted the deletion. The response carries no data.
Note that this says nothing about whether the contact existed beforehand: how a delete of an unset contact is reported is the ops-service's decision, not Prism's, and if it refuses you will see a 502 rather than a 404.
message is the fixed string Alternate contact deleted.
Authentication failed: the X-API-Token header was missing, malformed,
expired or not recognised.
This response is text/plain, not JSON. It is written by
http.Error in the authentication middleware, which runs before any
handler and therefore before anything that would build a JSON envelope.
A client that unconditionally JSON-parses response bodies will fail on
this one, so check the status code first.
The token is valid, but it is not allowed to act on this tenant.
An API token is minted inside one tenant and stays bound to it for life.
Sending it to a path whose tenant segment names a different tenant is
refused here, in middleware, before the operation runs, so this says
nothing about the resource you asked for, only about which tenant the
path named. Check the tenant server variable against the console the
token was created in.
No tenant matches the tenant segment of the request path. Nothing about the account or the contact produces a 404; those are 502.
The deletion did not happen. Every upstream outcome lands here,
including an unrecognised {type} (primary among them), an account
that does not exist, and an unpaired self-hosted install. message
carries the upstream reason verbatim.
There is no request body on this operation, so unlike the two PUTs there is no 400 branch at all.