---
title: "Update Whitelist Note"
method: PATCH
path: "/api/admin/users/{user_id}/whitelist"
tags: ["admin-users"]
---

# Update Whitelist Note

`PATCH /api/admin/users/{user_id}/whitelist`

## Request

- Base URL: `https://api.tintin-x.com` (the document declares no server; this is the origin it was published from)
- URL: `https://api.tintin-x.com/api/admin/users/{user_id}/whitelist`
- Auth: HTTP bearer

Edit the note on an existing whitelist grant.

Deliberately note-only. Before this existed the sole way to correct a note
was remove-then-re-add, which reset `whitelisted_at` / `whitelisted_by`
and destroyed the record of when the exemption started and who approved it
— exactly the provenance a 2B contract exemption needs to keep.

Nothing about the exemption's SCOPE changes here: expiry, no_expiration
and the is_whitelisted flag itself are untouched, so editing a note can
never accidentally extend or revoke someone's access.

## Path parameters

- `user_id` string, required

## Request body

- WhitelistNoteRequest: Edit the note on an EXISTING whitelist grant. Separate from WhitelistRequest because re-POSTing to change a note would reset `whitelisted_at` / `whitelisted_by` and re-open the expiry choice — losing when and by whom the exemption was originally granted. The note is the only field this touches. Free text on purpose: it carries whatever the 2B contract needs (contract no. / wire amount / period / who signed it), and those vary per deal. The column is TEXT, so multi-line is fine; the cap is here to keep an admin typo from writing a novel into every list response.
  - `note` string, nullable

## Response `200`

Successful Response

- unknown

## Other responses

- `422`: Validation Error

---

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