Get inbound router
Read an agent’s inbound router settings, its shared identity, and the tasks the router can choose from.
GET
Get inbound router
The inbound router lets an agent choose which of its tasks answers a new inbound conversation, using your rules and what the lead writes. In the app this is Let your agent choose the task. See Tasks that work together.
In the API an agent is a
master_workflow and a task is a workflow. The agent ID goes in the path, and tasks appear in fields such as default_workflow_id and target_workflow_id.
How the router picks a task
For each new conversation, the router goes through these steps in order and stops at the first one that decides. Each step has alayer value, shown in List decisions.
If something fails along the way, the conversation goes to the default task so the lead still gets an answer (
error_fail_open).
Before you start
- The inbound router is not available on every account. Without it, every endpoint in this section returns 403
inbound_router_not_enabled. - MCP keys need
workflows:readto read andworkflows:writeto make changes. Full-access API keys need nothing else. - Every change requires
"confirm": truein the body. Without it, the API returns 400confirmation_requiredand changes nothing. - Errors return a stable code in
error, such asagent_group_not_found. Map the code to your own message. - To choose which numbers and inboxes reach the agent, see List entry points.
Authorizations
Path Parameters
Response
Router of the agent.
Last modified on September 28, 2026
Get inbound router