### Answer Yes, the inbound webhook is exactly the mechanism designed for pre-agent routing decisions. [(1) ]() ## How It Works When an inbound call comes in, the webhook is triggered before the call is connected and before a call object is created. The call stays in a ringing state while waiting for your webhook response. This gives you a 10-second window to make routing decisions in Make.com. ## Routing to Different Agents In your webhook response, you can use

override_agent_id

to route to different agents based on your time-based logic evaluated in Make.com:

json
{
  "call_inbound": {
    "override_agent_id": "agent_12345",
    "override_agent_version": 1,
    "dynamic_variables": {
      "customer_name": "John Doe"
    }
  }
}

## Key Points for Your Use Case 1. Evaluate conditions in Make.com before responding to the webhook—check

office_hours

,

after_hours

,

holidays

logic there 2. Return different

override_agent_id

values based on your conditions (e.g., one agent for office hours, another for after hours) , [(2) ]() 3. To reject calls (e.g., during holidays) : respond with 200 status code without the

override_agent_id

field [(1) ]() ## Setup Requirements - Unset the default

Inbound Call Agent

in phone number settings if you want full webhook control - Enable the

Inbound Webhook

and point it to your Make.com webhook URL - Your Make.com scenario should evaluate time/conditions and return the appropriate agent ID This approach eliminates LLM latency entirely for routing since the decision happens at the webhook level before any agent is engaged.

​ To learn more, see the sources I considered: [[1] Inbound webhook](https://docs.retellai.com/features/inbound-call-webhook) [[2] Importing existing phone number to multiple agents via API](https://discord.com/channels/1186424376300679209/1418871771045564509) ​

Feel free to tag @AI Evy with additional questions. I also appreciate feedback, it helps me improve.