Lead routing

Overview

When a new lead arrives, Fondaro gives it an owner in this order:

1. Your own rules first. The most specific matching rule wins (a rule for the lead's Growth plan, language or tag beats a catch-all); among equally specific rules, the lower priority wins.
2. Smart routing when none of your rules match. It is one catch-all rule Fondaro creates when your organization first gets a plan, on by default and switched off only by you. It hands leads to the active people on your team: when some of them list the lead's language on their profile (agent_profiles.languages, matched on the primary subtag, so nl-BE reaches nl), whichever of those got a lead longest ago; otherwise the whole team in a counted rotation, where nobody gets a second lead before everyone has had one.

Smart routing never overrides a rule you wrote, and switching it off keeps it off: Fondaro does not switch it back on.

The endpoints on this page use the dashboard's Clerk bearer token and resolve the organization from the request. Reading Smart routing is open to every member; everything else under /lead-routing is limited to organization admins, and a member receives 403.

Endpoints

Smart routing

curl https://api.fondaro.com/lead-routing/smart \
  -H "Authorization: Bearer <clerk session token>"
# { "enabled": true, "teamUserIds": ["user_2abc...", "user_2def..."] }

curl -X PUT https://api.fondaro.com/lead-routing/smart \
  -H "Authorization: Bearer <clerk session token>" \
  -H "Content-Type: application/json" \
  -d '{ "enabled": false }'
# { "enabled": false }

teamUserIds is the active team in turn order: the people Smart routing hands leads to right now. PUT takes { "enabled": boolean } and returns the new state. On creates the rule if it does not exist yet or reactivates it; off deactivates it. The call is idempotent.

The rule behind the switch carries the strategy smart. It has no conditions and no members of its own (the rotation reads the team at the moment a lead arrives, so someone who joins is included and someone who leaves drops out), and it sorts after every rule you can write (priority 1000). It is only ever changed through this switch: it is not in GET /lead-routing/rules, and PATCH or DELETE on its id returns 404.

Your own rules

curl -X POST https://api.fondaro.com/lead-routing/rules \
  -H "Authorization: Bearer <clerk session token>" \
  -H "Content-Type: application/json" \
  -d '{
    "language": "sv-SE",
    "strategy": "round_robin",
    "priority": 0,
    "members": [
      { "userId": "user_2abc...", "weight": 0, "sortOrder": 0 },
      { "userId": "user_2def...", "weight": 0, "sortOrder": 1 }
    ]
  }'

The assignment reason on a lead

GET /crm/leads/:id returns lead.assignmentReason for every member who can see the lead, so the lead page can say "Assigned to {name}":

{
  "lead": {
    "id": 12345,
    "assignmentReason": {
      "assigneeIds": ["user_2abc..."],
      "at": "2026-09-26T10:14:03.000Z"
    }
  },
  "origin": { }
}

It is read from the lead's assignment history: set when the newest change to the lead's owners is Fondaro routing it on arrival (people added, nobody removed, no team), and null once a person has changed the owners since, or when nothing routed it. The ids are Clerk user ids of the lead's owners at that moment.