Routing Groups V2: Sub-Rules, Hunt-Stop Codes, and a Full JSON API

Routing Groups V2 is live for all voice buyers on TelecomsXChange (TCXC). The simple idea stays intact, and three things operators keep asking for are now built in: sub-rules for per-destination and per-caller routing, hunt-stop codes that stop pointless retries, and a full REST API with MCP support so AI agents can manage routing too.

A routing group is a simple idea. Take the routes you have bought in the Market, put them in a named group, and pick a policy for how calls flow through them. Point your traffic at the group, dial its tech prefix (for example 444729#) in front of the number, or set it as the default on your SIP account, and the platform picks the route.

That idea has not changed. What changed is everything around it. Routing Groups V2 adds three big things:

• Sub-rules route specific destinations or callers differently, inside one group.
• Hunt-stop codes stop retrying calls that cannot succeed.
• A full REST API, plus MCP support, so AI agents can manage your routing too.

Plus a rebuilt editor. Here is each one, with the details that matter.

The three routing policies

Every group runs one of three policies:

Details worth knowing:

• LCR returns up to 6 routes per call, ranked by price. Routes with the same price are tied randomly, so they share traffic instead of one starving.
• Load Balancing weights are relative. Weight 50 out of a total of 150 means roughly a third of the calls. The editor now shows the percentage next to each weight, so you do not have to do the math. Failover still works: if the chosen route rejects the call, the next one takes it.
• Failover Order does exactly what you set. No re-ranking, no surprises.

Before a route makes the candidate list, it has to pass some checks: a valid rate for the dialed prefix, your max-price cap, the route capacity limit, the seller caller-ID rules, and your available balance. If a route fails a check, the next one is tried. Your call does not fail just because the cheapest route was full.

Sub-rules: different routing for different traffic

This is the headline feature.

Until now, a group treated every call the same. If you wanted UK mobile handled differently from the rest of your traffic, you needed a second group, a second tech prefix, and switch config to match.

A sub-rule fixes that. It is a routing override that lives inside your group. Each rule says: if the call looks like this, use these routes instead.

A rule can match on:

• Destination prefix (CLD), the first digits of the number being called. Example: 447 matches UK mobile.
• Caller prefix (CLI), the first digits of the caller number. Or the special value EMPTY, which matches calls with no caller ID.

Each rule has its own policy and its own route list. Think of it as a small routing group nested inside your routing group.

Three rules of matching

This is where routing mistakes happen, so read these:

1. Rules are checked top-down. First match wins. A more specific prefix does not beat an earlier rule; order decides. Put specific rules first.
2. A blank field matches everything. If you fill in both destination and caller, both must match.
3. No match? The call uses the group default routes, like before.

Here is a setup that used to take three groups and now takes one:

Group: Wholesale-Main  (default: LCR across 6 routes)
│
├── Rule 1  destination starts with 447
│         → Failover Order: PremiumCarrier-A, then PremiumCarrier-B
│
├── Rule 2  caller ID is empty
│         → Load Balancing across carriers that accept no-CLI calls
│
└── No match  → default: cheapest of the 6 routes

Performance: rule matching is one indexed database lookup during call setup. We added the indexes in the same release. A long rule list will not slow your calls down.

Hunt-stop codes: stop retrying calls that cannot succeed

Failover is great when a route is broken. It is harmful when the route is fine and the answer is no.

Example: the first carrier returns 486 Busy Here. The person you are calling is busy. Trying the same number through four more carriers will not change that. It just wastes call attempts, adds delay, and can make the far phone ring again.

So each group now has a hunt-stop list: SIP codes that stop the hunt immediately and return the real answer to the caller. New voice groups start with three sensible defaults:

• 486 Busy Here
• 404 Not Found
• 604 Does Not Exist Anywhere

Edit the list however you like. Click the quick-add chips in the editor, or type any comma-separated codes from 400 to 699. Bad values are dropped and duplicates removed automatically.

And if your traffic wants aggressive retries, dialer traffic for example, just clear the list. Hunting then continues through every route, like before.

One related note: a route can define a backup host, which is tried before the hunt moves to the next carrier. Carrier redundancy and price failover stay separate things.

The REST API

Everything above is scriptable, over clean URLs at apiv2.telecomsxchange.com with digest auth. The API drives the exact same code as the UI, so there is no gap between what the portal can do and what your automation can do.

# List all groups, with their routes and sub-rules
curl --digest -u 'login:api_key' \
  'https://apiv2.telecomsxchange.com/buyers/rg/list'

# Create a group
curl --digest -u 'login:api_key' \
  -d 'name=Wholesale-Main&policy=lcr' \
  'https://apiv2.telecomsxchange.com/buyers/rg/add'
# -> {"status":"success","i_routing_group":123, ...}

# Add a sub-rule: destination starts with 447
curl --digest -u 'login:api_key' \
  -d 'subrule_cld_prefix=447' \
  'https://apiv2.telecomsxchange.com/buyers/rg/123/add_rule'

# Add a purchased route (connection 8721) to group 123
curl --digest -u 'login:api_key' -X POST \
  'https://apiv2.telecomsxchange.com/buyers/rg/123/entry/add/8721'

# Set entry 4551 weight to 70 (Load Balancing groups)
curl --digest -u 'login:api_key' -X POST \
  'https://apiv2.telecomsxchange.com/buyers/rg/123/entry/4551/set_weight/70'

# Change policy and hunt-stop codes
curl --digest -u 'login:api_key' \
  -d 'name=Wholesale-Main&policy=order&hunt_stop_codes=486,404' \
  'https://apiv2.telecomsxchange.com/buyers/rg/edit/123'

The full endpoint map:

Every response is JSON with a status and a plain-English message. Validation is strict, and errors tell you what is wrong:

• Connection IDs must be integers.
• Weights must be whole numbers, 1 to 100.
• You can only add routes you have actually purchased in the Market.
• Adding the same route twice is rejected with a clear message.
• Reordering is only allowed where it makes sense (Failover Order groups).

The list call returns the whole tree, groups, routes in effective order, and sub-rules with their route counts, so you can diff live config against what your automation expects, in one request.

Handing the keys to an AI agent

Routing groups are also exposed through the TCXC MCP connector, the same integration that already gives AI models access to the Market, route testing, live calls, and CDRs. MCP (Model Context Protocol) is the open standard frontier models like Claude use to work with external systems. Plug the connector into your AI assistant, and routing management becomes something you ask for rather than something you click through.

That sounds like a demo feature. It is not. What makes it real is the combination: the connector already lets an agent observe (call records, live calls, quality summaries, market rates) and test (place a real test call through a specific route). Now it can also act on routing. Observe, test, act, that is a complete control loop.

Some things that become practical:

• Plain-language routing changes. "Send UK mobile through Carrier A, fall back to B, and stop hunting on busy." The agent translates that into the rule, the route order, and the hunt-stop config, and reads the group back to confirm what it did.
• Closed-loop quality management. An agent watches your CDRs, notices ASR dropping on a destination, runs a test call through the current route and the alternatives, then shifts Load Balancing weight toward the route that actually completes calls. What used to be a Monday-morning NOC task becomes a five-minute loop.
• Cost optimization that keeps up with the market. Sellers change rates constantly. An agent can compare your LCR groups against current Market offers and flag, or make, the swap when a better route appears.
• Incident response at machine speed. A carrier starts failing at 3 a.m. The agent sees the failure spike, drops the sick route, confirms traffic is completing on the fallback, and leaves you a summary instead of an outage.

Two design decisions matter a lot here, and they are worth being explicit about.

First, the API strictness is what makes agent access safe. Every action is small and explicit, add one rule, set one weight, not "upload a new config file." Typed validation rejects nonsense, agents can only touch routes the account has actually purchased, and structured errors give the model something it can read and correct. And because the list endpoint returns full state in one call, an agent can verify every change it makes. A well-behaved agent needs exactly this: a small action space, hard walls, and instant feedback.

Second, you decide how much autonomy to grant. The MCP credentials are your API credentials, so scope them to a buyer account. Sensible teams start with read-and-recommend (the agent proposes, a human clicks approve) and graduate to autonomous changes for low-risk actions like weight adjustments, keeping human sign-off for big traffic shifts. The API does not force a philosophy; it just makes both modes possible.

We think this is where telecom operations are heading: not fewer engineers, but engineers who describe intent while agents handle the mechanical loop of watch, test, adjust. Routing Groups V2 was built so that loop has something solid to run on. For a closer look at agents on the routing desk, read Wholesale Routing That Doesn't Clock Out When You Do.

The new editor

The UI was rebuilt around how people actually manage routing:

• Drag and drop. Available routes sit in a searchable panel; drag them into the group. Search filters instantly by route or seller name.
• Policy cards that describe behaviour in a sentence, instead of a radio button labelled "weight".
• Priority badges on Failover Order groups, and traffic-share percentages on Load Balancing groups.
• A better list view: every group shows its routes, sellers, rules, and policy at a glance.

Fixes that shipped alongside

A release like this is a chance to pay down debt, so we did:

• Route selection now fully resets its state between candidates. Previously, in one edge case, a route with no rate for the dialed prefix could inherit rate data from the previous route. Fixed.
• Rule validation was tightened; a type-coercion bug could let an invalid rule through.
• Setting a weight no longer changes how the route list is displayed.
• Search and route-name output is properly escaped, end to end.

None of that needed a headline. But you would want to know.

Try it

Routing Groups V2 is live for all voice buyers. Open Routing Groups in your buyer portal, point your tooling at apiv2.telecomsxchange.com, or connect the TCXC MCP connector to your AI assistant and ask it to show you your groups. If you find a sharp edge we missed, tell us, that is what the message center is for. Questions? Contact the TelecomsXChange team.