Update team routing settings
/v1/routing/settings/{id}org.permission.routing.updateorg.admin.team.writeThe API key or user must hold at least one of them. Legacy roles still work; prefer the others for new keys.
Updates a team's routing settings by its unique team ID.
Team routing settings
Team routing settings decide how routing treats the agents on one team. They set which queues the team works, how much work each agent can hold at once, and whether routing is turned on for the team.
Routing works through teams. A team is a group of users, and its routing settings are a separate record, one per team, that admins edit in Kustomer's routing settings. The record is addressed by the team ID and is created the first time you save it. Agents can route only through teams that have settings with enabled: true.
When an agent signs in to routing, their work session is tied to one of their teams, and that team's settings supply the session's queues and capacity. An agent on several routing teams chooses which one to work as, and can switch; switching changes which queues they draw from.
Queues
queues lists up to 10 queue IDs the team works, and every ID must belong to an existing queue. Agents on the team are offered items only from these queues. When you change the list, Kustomer updates the queues on the team's active work sessions straight away. externalQueues takes at most one external queue name, such as amazon-connect, for teams that take calls from a third-party phone system that runs its own queues.
Capacity
Capacity is how much work an agent can hold at once. Each assigned work item uses capacity equal to the itemSize of its queue, and a paused (snoozed) item uses none.
| Field | Meaning |
|---|---|
workItemCapacity |
Total capacity for each agent on the team, from 1 to 50. Defaults to 1. |
capacity |
Optional limits by priority: an object whose keys are queue priority numbers and whose values (1 to 50) are the most capacity items of that priority may use, such as { "1": 2, "2": 3 }. |
Per-priority limits keep low-priority work from filling every slot. On the work session, they appear as the capacity array, with limit and remaining for each priority.
Which endpoint to use
| To | Call |
|---|---|
| List settings for every team | GET /v1/routing/settings |
| Read one team's settings | GET /v1/routing/settings/{id}, with the team ID |
| See the settings for the signed-in user's teams | GET /v1/routing/users/current/settings |
| Create or change a team's settings | PUT /v1/routing/settings/{id}, with the team ID |
PUT creates the settings if the team has none and otherwise changes only the fields you send; queues, when sent, replaces the whole list. GET /v1/routing/settings/{id} returns 404 for a team whose settings have never been saved. Updating settings needs a team-admin role (org.admin.team.write) or org.permission.routing.update.
Path parameters
Team ID
"5f184e74c61792001af42e49"Request body
application/jsonrequiredResponses
OK