Update queue by ID

When a conversation needs an agent, routing places its work item in a queue and then offers it to an available agent on a team that works that queue. Admins manage queues in Kustomer's routing settings, and teams choose the queues they serve in their team routing settings. A conversation gets a queue in one of three ways: a queue rule matches it, something sets the queue directly (a workflow, an agent transfer, or the queue on a work item), or nothing matches and it falls through to the default queue.

Every org has one system queue, returned with system: true and named DEFAULT_QUEUE, that catches conversations no rule matches. Queue rules can't target it, and the only field you can change on it is restrictTransfersByUsers: an update to the default queue must send that field and nothing else.

Priority and item size

These two fields are copied onto each work item every time it enters the queue, and they drive routing:

Team routing settings can also cap how much capacity each priority may use, so an agent's slots aren't all filled by low-priority work.

Other fields

• name is required; displayName is what agents see, and description is free text.
• key is an optional stable identifier you choose, unique among the org's active queues. Queue rules can pick a queue by key with queueKey, and GET /v1/routing/queues?key= finds a queue without knowing its ID, which helps when the same setup exists in several orgs.
• restrictTransfersByUsers, when true, removes the queue from the list agents can transfer a conversation to. Queue rules can still send work there.

Queues deleted in the Kustomer app are kept as deleted records. Lists leave them out unless you pass all=true, which is useful when an older work item points at a queue that no longer appears.

Which endpoint to use

PUT requires name and changes only the fields you send. Updating a deleted queue fails with 409 Conflict, and so does creating a queue once the org has reached the number of queues its subscription allows.