---
title: "End your management of an account"
method: DELETE
path: "/v1/accounts/{account_id}/management"
tags: ["Accounts"]
---

# End your management of an account

`DELETE /v1/accounts/{account_id}/management`

## Request

- Base URL: `https://app.beel.es/api`
- URL: `https://app.beel.es/api/v1/accounts/{account_id}/management`
- Auth: HTTP bearer

Ends the management relationship over an account you provisioned: you lose access to it,
and its NIFs stop counting towards your billable usage from the next billing cycle.

- **The holder:** keeps the account, its NIFs and its invoices, and becomes responsible
  for their own subscription. Nothing is deleted or anonymised.
- **Reversible:** only while the account stays unclaimed. Provisioning the same email
  again reactivates it (see `POST /v1/accounts`), and only the manager who ended the
  relationship can do so. Once the holder claims the account it is theirs, and getting the
  management back needs their consent, not just their email address.
- **Entitlement:** requires `manage_accounts`.

## Path parameters

- `account_id` string, uuid, required

## Response `204`

Management ended. The account remains active under its holder.

## Other responses

- `401`: Missing or invalid authentication. Like every other error, `message`/`detail` is localized according to `Accept-Language` (`es`, `en`, `ca`); defaults to English when the header is missing or asks for none of those.
- `403`: Every cause listed under the plain `403` above, plus one specific to writes on the account's control plane: `LIVE_CREDENTIAL_REQUIRED`, returned when the call is made with a test API key (`beel_sk_test_…`). Members, invitations and grants are shared between Test and Live, so changing them is always a real change to the real account — there is no sandbox rehearsal of it. The same applies to changing a managed account's access level and to ending its management: both act on an account that may already be invoicing. Use your live API key or the dashboard; reading these resources keeps working with either key, and so does the whole account provisioning flow (provisioning and claim tokens), which creates an inert account and is what you are meant to rehearse in Test — with your test key, but still only if your subscription carries the `manage_accounts` entitlement: that gate applies in Test exactly as it does in Live, and without it the rehearsal answers `403 FEATURE_NOT_AVAILABLE` rather than this code. Accounts that have no live mode manage their people from the dashboard.
- `429`: Rate limit exceeded. `RATE_LIMIT_EXCEEDED` when the request rate of your credential is over its limit; `TOO_MANY_REQUESTS` when an email the operation sends is held back because too many went out to that recipient in a short time. Either way, retry after the `Retry-After` seconds. `QUOTA_EXCEEDED` is the other `429`: the operation would go over a quota of your plan for the current period (issued invoices, for instance). Retrying does not help until the quota resets or the plan changes. `error.details` carries `feature_code`, `current_usage`, `quota_limit` and `reset_date`, and `RateLimit-Reset` the seconds until the reset when it is known.
- `500`: Internal server error
- `default`: Any status code the operation does not list above. Every operation declares it, so a generated client always has a branch to fall into and never loses the cause of a failure it did not anticipate. This is where the transport-level answers land — `405`, `406`, `415` and `429` — together with any status a future version of the API starts returning. All of them carry the same error envelope as the codes listed explicitly, so `error.code` is what tells them apart: switching on the status code alone is not enough. See «Transport-level errors» in the API description for when each one is produced. A `402` carrying `SUBSCRIPTION_REQUIRED` lands here when the account has no active subscription. `error.details` says why and what to do: `current_status` (absent if it never had one), `required_permission` and `action`. A `503` carrying `SERVICE_UNAVAILABLE` lands here too, with a `Retry-After` header: a dependency of BeeL itself (the database, the email provider) was momentarily unavailable and nothing was done. Retry after those seconds. A `502` carrying `EXTERNAL_SERVICE_ERROR` also lands here: an outbound integration the operation depends on failed or did not answer in time. It is a transient condition — retry with the same `Idempotency-Key` where the operation accepts one. One exception to the envelope: a failure of the network edge that never reaches the application (`502`, `503`, `504`, `524`) is generated by Cloudflare and its body is not BeeL's — it may not even be JSON. Treat those as "no answer", and retry.

---

[API](https://skmtc.dev/beel/apis/beel-public-api.md) · [All operations](https://skmtc.dev/beel/apis/beel-public-api/llms.txt) · [OpenAPI document](https://skmtc.dev/beel/apis/beel-public-api/revisions/ffbc0ae31f79?raw)