Remove a profile

What it removes

The profile itself, and its place in your organisation's own menu. After this it is gone from GET /v1/profiles, from the profile pickers your colleagues see, and from the count GET /v1/quotas reports against your profile allowance.

This is the counterpart of POST /v1/profiles. A profile created by mistake used to stay in your organisation for good — the nearest thing to a way out was renaming it into something obviously dead with PATCH, which left it in every picker and still spent one of your slots.

The granskare are left where they are

A granskare can belong to more than one profile — GET /v1/profiles marks one that does with "shared": true — so removing a profile never removes the granskare it named. That is deliberate: a granskare deleted out from under another profile would leave that profile naming a reviewer that no longer exists, and its next analysis would fail rather than run smaller.

The cost is that a granskare only this profile named stays stored after the profile is gone. It appears in no picker and runs in no analysis; it is simply still there, and can be attached to another profile with PATCH /v1/profiles/:id. There is no way to remove a granskare over this API — tell us if you need one gone.

An action written only for this profile becomes visible to all of them

An action is often written for one kind of audit, and says so by naming the profiles it fits. Remove a profile and you may remove the last profile some action still names — and that action does not go away with it. It starts appearing for every profile instead, both in the audit tool's action menu and in GET /v1/actions. An action that names a profile you kept as well is not affected; it takes all of an action's named profiles being gone.

That is the same rule GET /v1/actions already documents — an action whose named profiles your organisation no longer has is shown rather than hidden, because an action that quietly disappeared would be indistinguishable from one the product had lost. It is worth knowing before you remove a profile, because the effect runs the other way from what "remove" suggests: your action menus get wider, not narrower, and nothing announces it.

If an action ends up somewhere it does not belong, point it at a profile you kept — an administrator can edit which profiles an action fits from the admin panel — or tell us and we will retire it.

What you may remove

Profiles your own organisation owns, and those only.

A profile your organisation inherited — one the platform publishes to every organisation — answers 403. It is not yours to remove, for the same reason it is not yours to edit: everyone else is running it too. Copy it first if what you want is a version of your own.

An id no profile in your organisation holds answers 404.

Removing twice is not an error you have to avoid

404 is also the answer to removing a profile that is already gone, so "removed" and "never existed" are one answer. If a response goes missing on the way back to you, send the request again: the second call cannot undo the first, and it cannot fail for having been sent twice.

Request

Errors

Rate limiting

Removing a profile never spends an analysis from your quota. It does tick the same hourly floor as creating and editing one — a guard against a client in a loop, reported by the X-RateLimit-* headers on this route's answers. A person clearing up after a mistake will never see it; a 429 here means something of yours is looping.