Confirm a root email change

POST 
/accounts/:accountId/contacts/email/accept

Completes the root email change started by POST /accounts/{accountId}/contacts/email/start, by presenting the one-time code AWS sent to the new address.

On success the AWS account's root email is changed, immediately and irreversibly from here. Signing in as the account root, and every future password reset, now go through the new address. Changing it back means running the whole two-step flow again from the new mailbox, which is only possible if someone can still receive mail there.

Prism's own record of the account is not updated by this. Nothing under /aws-accounts reflects the root email; it lives at AWS and is read back through POST /accounts/{accountId}/contacts/get.

A wrong or expired code is a 502, not a 400. Prism validates nothing here (not the code, not the address), so every rejection comes from upstream and arrives with the upstream status discarded. A 502 from this operation is far more likely to mean "wrong code" than "the service is down"; read message before assuming an outage. Restart from .../email/start to get a fresh code.

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

The root email was changed at AWS. Prism's own record of the account is unchanged, because it never held the root email.

There is no data, and message is the fixed string Root email updated successfully.

400

The request body is not valid JSON. This is the only thing about the body that Prism checks; a wrong code, an expired code and a missing field are all forwarded and fail upstream as a 502.

401

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.

403

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.

404

No tenant matches the tenant segment of the request path. An AWS account that does not exist is a 502, not a 404.

502

The root email was not changed. This is where a wrong or expired one-time code lands, alongside every other upstream outcome: no pending change for that address, the ops-service unreachable, this self-hosted install not paired with CloudKeeper SaaS, or the account not existing. message carries the upstream reason verbatim and is the only way to tell a bad code from an outage.