CRM v1 current
crm.
Changes who owns a client, naming the client and the team member (by name or email). If either is ambiguous it refuses with the list.
Last updated
POST /api/v1/actions/crm.owner_assigned- Key scope
crm.owner_assigned@1- Workspace permission
api.crm.owner_assignedoff by default
Two permissions, not one
Both are needed: a key with that scope, and the workspace owner having switched the permission on. Holding the key is not enough — they are two decisions made by different people.
Request
| field | type | rules | |
|---|---|---|---|
client | string | required | min 1 · max 200 |
owner | string | required | min 1 · max 200 |
Response — output when status is done
| field | type | rules | |
|---|---|---|---|
clientId | string | required | |
clientName | string | required | |
ownerUserId | string | required | |
ownerName | string | required |
Example
# One request, one idempotency key: retrying with the same key never runs twice.
curl -X POST https://niiko.org/api/v1/actions/crm.owner_assigned \
-H "Authorization: Bearer nk_…" \
-H "Idempotency-Key: $(uuidgen)" \
-H "Content-Type: application/json" \
-d '{
"client": "…",
"owner": "…"
}'
# 200 → done · 202 → pending_approval (a person signs later) · 4xx → refused, with a named reasonWhy it may refuse
Each reason names who can fix it and how. With reason stale, detail.message says what to do.
cliente_no_encontradocliente_ambiguodemasiados_clientespersona_no_encontradapersona_ambiguasin_permiso
In the clients
| @vorluno/niiko-sdk | niiko.assignedOwner() |
| niiko (Python) | niiko.assigned_owner() |
| niiko-cli | niiko run crm.owner_assigned |
| n8n-nodes-niiko | crmOwnerAssigned |
| niiko-mcp-server | crm_owner_assigned |