---
title: "Write Client"
method: PUT
path: "/api/autopilot/clients/{client_id}"
tags: ["autopilot"]
---

# Write Client

`PUT /api/autopilot/clients/{client_id}`

## Request

- Base URL: `https://api.taxcompass.it` (the document declares no server; this is the origin it was published from)
- URL: `https://api.taxcompass.it/api/autopilot/clients/{client_id}`
- Auth: HTTP bearer

Replace one customer wholesale (see the store on why it is not a merge).

A PUT with an unknown id is a 404, never an upsert: ids are server-minted, so
a body carrying one the caller was never given is a bug or a probe — and
creating a row at a caller-chosen id is how one user plants an id another
user's URL then resolves.

## Path parameters

- `client_id` string, uuid, required

## Request body

- ClientCreate: The write body for one invoice client — create and full replace alike. A client is editable at any time (nothing here is fiscally frozen the way an issued invoice is), so the update path replaces the whole record instead of patching: the dialog that collects it (AP-050) always holds every field, and a partial merge is how a cleared PEC survives an edit. Identifiers are checked **only for Italian clients**: a German VAT number is neither a partita IVA nor a codice fiscale, and running either checksum on it would reject a perfectly valid customer. Foreign codes are length-and-alphabet bounded to what ``IdCodice`` accepts instead.
  - `display_label` string, required
  - `country` string
  - `is_business` boolean
  - `codice_destinatario` string, nullable
  - `denomination` string, nullable
  - `given_name` string, nullable
  - `family_name` string, nullable
  - `partita_iva` string, nullable
  - `codice_fiscale` string, nullable
  - `pec` string, nullable
  - `street` string, nullable
  - `cap` string, nullable
  - `comune` string, nullable
  - `provincia` string, nullable

## Response `200`

Successful Response

- ClientRead: One stored client as the API returns it (``details`` decrypted). ``verified`` is tri-state and read-only (it is not on :class:`ClientCreate` — a client cannot declare itself verified): ``True`` the identifier is on file, ``False`` it is not, ``None`` nobody asked. The third case is ordinary — a registry outage, or a client with no Italian identifier to check — so a UI renders it as "unchecked", never as a failure.
  - `display_label` string, required
  - `country` string
  - `is_business` boolean
  - `codice_destinatario` string, nullable
  - `denomination` string, nullable
  - `given_name` string, nullable
  - `family_name` string, nullable
  - `partita_iva` string, nullable
  - `codice_fiscale` string, nullable
  - `pec` string, nullable
  - `street` string, nullable
  - `cap` string, nullable
  - `comune` string, nullable
  - `provincia` string, nullable
  - `id` string, uuid, required
  - `created_at` string, date-time, nullable
  - `verified` boolean, nullable
  - `verify_detail` ClientVerification: What the registry answered about one client's identifier, if it was asked. Metadata only. The identifier itself is identity — it lives in the encrypted ``details`` envelope — so it is deliberately absent here and from the column this mirrors: a verification record must not become a second, plaintext copy of the customer's partita IVA.
    - `provider` string, required
    - `kind` 'piva' | 'cf', required
    - `status` 'found' | 'not_found' | 'unreachable', required
    - `checked_at` string, date-time, required
    - `reason` string, nullable

## Other responses

- `422`: Validation Error

---

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