---
title: "Deactivate a customer"
method: POST
path: "/customers/{customer_id}/deactivate"
tags: ["Customers"]
---

# Deactivate a customer

`POST /customers/{customer_id}/deactivate`

## Request

- Base URL: `https://developers.ozav.io/v2`
- URL: `https://developers.ozav.io/v2/customers/{customer_id}/deactivate`
- Auth: one of:
  - API key in header `X-API-Key`
  - HTTP bearer

Stops new money movement for the customer. Card purchases are declined with `account_inactive`. New cards, transfers (`POST /transfers`), account payouts and wallet sends are refused with `403 CUSTOMER_DEACTIVATED`; withdrawals through the custody API are refused with `403 USER_DEACTIVATED`. Deposits sent to the customer's wallets and accounts still arrive and are credited, but cannot be spent until you reactivate. It applies to test keys too, so you can try it in the sandbox.

Operations created before the deactivation finish, except wallet sends still waiting for approval or a delay, which are refused when they would execute. Self-custody transaction intents are not affected: OZAV does not sign them.

Calling it again on a deactivated customer changes nothing and returns the date of the first deactivation. This is your own switch: it does not lift, and does not reveal, any restriction OZAV applies for compliance reasons. Your organization's own account cannot be deactivated (`422 CUSTOMER_DEACTIVATION_NOT_ALLOWED`).

## Path parameters

- `customer_id` string, required

## Response `200`

The customer's deactivation state.

- CustomerDeactivation: Whether you deactivated the customer through the API. It reflects only your own deactivation.
  - `object` 'customer_deactivation', required: Resource type discriminator; always `customer_deactivation`.
  - `customer_id` string, required: The `ozav_cus_` id of the customer.
  - `deactivated` boolean, required: `true` while your deactivation is in force.
  - `deactivated_at` string, date-time, nullable, required: When you first deactivated the customer; `null` when active.

## Other responses

- `401`: Missing or invalid API key.
- `403`: The organization lacks the entitlement (code ENTITLEMENT_REQUIRED) or the key lacks the scope (code INSUFFICIENT_SCOPE). On money-moving requests (POST /transfers, POST /wallets/{wallet_id}/transfers) a compliance hold on the customer answers with code COMPLIANCE_HOLD: the hold is reviewed and lifted on OZAV's side; retrying does not clear it. When the only hold is a pause until pending onboarding documents are received, a withdrawal answers CUSTOMER_DOCUMENTS_PENDING instead: send what `requirements` on GET /customers/{id} lists; OZAV lifts the pause after reviewing it. On OZAV Services (live without the platform's KYB), any API outside decisions, screenings, lists and self-custody wallets answers with code PRODUCTION_NOT_ACTIVATED.
- `404`: The resource does not exist, is not visible to the caller, or the id was malformed for this position (see "Resource ids" under Errors). These share one status; `code` and `message` tell them apart.
- `422`: The request is well-formed but cannot be fulfilled - e.g. a `rail` that is not served (see `Rail.x-ozav-rail-availability`).

---

[API](https://skmtc.dev/ozav/apis/ozav-api.md) - [All operations](https://skmtc.dev/ozav/apis/ozav-api/llms.txt) - [OpenAPI document](https://skmtc.dev/ozav/apis/ozav-api/revisions/4133dc2109d7?raw)