Create queue rule

Admins build queue rules in Kustomer's routing settings, as one ordered list for the whole org. Routing runs the list when a conversation needs an agent and has no queue yet: no queue or external queue has been set, and no user is assigned. It checks the enabled rules from top to bottom and stops at the first match, so a specific rule such as "VIP customers" must sit above a broad one such as "All email". If no rule matches, the conversation goes to the org's default queue. A conversation that already has a queue, for example one set by a workflow or a transfer, skips the rules.

Criteria

criteria holds two lists of conditions. A rule matches when every condition in and is true and, if or has any conditions, at least one of those is true. A rule needs at least one condition in either list.

{
  "and": [
    { "conversation_channel": { "operator": "equals", "value": "email" } },
    { "customer_custom_isVipBool": { "operator": "equals", "value": true } }
  ],
  "or": []
}

Each condition is keyed by a field name prefixed with the object it reads: conversation_, customer_ or message_ (the conversation's latest message). Custom attributes use _custom_, as in customer_custom_isVipBool. GET /v1/routing/queue-rules-criteria lists the fields you can use and the operators each field type supports; strings take equals, not_equals and contains, and numbers take equals, gte and lte. Every condition needs a value, except those using is_set or not_set.

Choosing the queue

A rule points at its queue in one of two ways:

Field	Use
`queue`	A fixed queue ID. It can't be the default queue; that fails with `409 Conflict`.
`queueKey`	A Handlebars template that is filled in from the conversation, customer and latest message, then matched against queue `key` values. One rule can route to many queues, such as one per region. If the result matches no queue, the conversation goes to the default queue.

Which endpoint to use

To	Call
List rules in the order routing checks them	`GET /v1/routing/queue-rules`, with `enabled=true` for active rules only
Read one rule	`GET /v1/routing/queue-rules/{id}`
Add a rule to the end of the list	`POST /v1/routing/queue-rules`
Change or remove a rule	`PUT` or `DELETE /v1/routing/queue-rules/{id}`
Reorder the rules	`PUT /v1/routing/queue-rules/order`
See which fields and operators rules can use	`GET /v1/routing/queue-rules-criteria`

Create and update both need name, criteria, and either queue or queueKey; send the whole rule on update, because leaving out queue clears it. Rules are enabled unless you send enabled: false. The order request must list every rule ID exactly once, or it fails with 400. The number of rules per org is capped by your subscription, and creating one past the cap fails with 409 Conflict. Rule changes apply to conversations routed after the change; conversations already in a queue stay where they are.

Queue rules

Criteria

Choosing the queue

Which endpoint to use

Request body

Responses