Settings & branding

PATCH /api/v1/organizations/{id}/ updates name, custom_domain, and branding (a JSON object — this dashboard's own Settings page writes logo_url/accent_color keys into it).

Both fields are plan-gated, and enforced server-side

Setting a real custom_domain requires your Organization's Plan.custom_domain flag; setting any real branding requires Plan.white_label. Both are on the growth plan and above, off on free and starter. The check happens in the API itself, not just in this dashboard's UI — a PATCH from a Free-tier Organization attempting either is rejected with a 400, not silently ignored. Clearing branding back to {} is always allowed, regardless of plan.

Danger zone — deactivate or delete

Two distinct, deliberately separate actions, each behind its own real Permission:

POST   /api/v1/organizations/{id}/deactivate/  -> status: suspended (reversible)
POST   /api/v1/organizations/{id}/reactivate/  -> status: active
DELETE /api/v1/organizations/{id}/  { "confirm_name": "<exact Organization name>" }

Deactivating flips status to suspended — reversible via reactivate, and checked live, on every request, by every real authentication choke point (bearer tokens, API keys, SCIM tokens, webhook dispatch) — a suspended Organization stops working immediately, not just at next sign-in. Deleting requires the request body's confirm_name to match the Organization's real name exactly (enforced server-side, not just a client-side confirmation box), cancels any active Paystack subscription first — and blocks the whole deletion if that cancellation fails, rather than deleting a still-billing Organization — revokes every active Session tied to it, and is a real, permanent soft-delete, not a status flag. Both actions can only ever target your own currently-active Organization, and both are structurally unreachable for the two reserved platform-internal Organizations, at the service layer, not just hidden in this UI. See Organizations & Applications for what happens if you delete your own home Organization.