Supply order: lines first, then your own vendors

Almost every business we speak to that sells data already has accounts at two or three reseller sites. They top them up by hand, they know which one is quick in the evening and which one goes quiet at month end, and when their own lines are busy someone switches a sale across by hand, or by a second integration that nobody enjoys maintaining.

Supply order and Vendor links put those accounts behind your lines instead. You keep the accounts, you keep paying them yourself at their own sites, and Routegate decides, sale by sale, which route gets the next one.

Connect the accounts you already have

A vendor link is your own account at a reseller site. In the dashboard, under Vendor links, you pick the site's script, paste the account's key and its address, and Routegate checks the key with one balance read before it saves anything. The key is sealed when it is stored. You will never see it again; the dashboard shows only its last four characters, and nothing in an API answer or a webhook carries it.

Some sites need one more step before they will take calls from us, usually adding Routegate's server address to the account's whitelist. The dashboard tells you which, per site, before you connect.

Then load the vendor's plans. Each one becomes something you can route to.

Choose the supply order

The supply order is one choice, set for your business as a whole and, where you want something different, per network:

• Lines then vendors sells from your lines, and when no line can serve the sale, goes to your vendors. This is the default.
• Vendors only never uses your lines on that network. Useful while a network's lines are being set up, or when you have no lines on it at all.
• Lines only never sends a sale on that network to a vendor.

There is deliberately no "vendors first". Your lines are the route you have already paid for, and they always rank ahead of a vendor when both are allowed. If you want a vendor to carry a network, choose vendors only for it.

 curl -X PUT "https://api.useroutegate.com/v1/routing/rules?mode=live" \
  -H "Authorization: Bearer $DASHBOARD_SESSION" \
  -H "Content-Type: application/json" \
  -d '{
    "sell_from": "sims_then_vendors",
    "networks": {
      "glo": { "sell_from": "vendors_only" }
    }
  }'

In the API the three choices are sims_then_vendors, vendors_only and sims_only. Routing rules are versioned, so every change is kept with who made it and when.

Give each plan a fallback order

Knowing that a sale may go to a vendor is half of it. The other half is which vendor, and which of that vendor's plans. Every plan you sell can have a fallback order: one to five vendor plans, one per vendor, tried in the order you list them after your lines.

When you build the order, the dashboard suggests the vendor plans that match on size and validity first, and it warns you, without refusing, when a step does not quite match: a 1GB plan routed to a vendor's 1.5GB plan, say. It does refuse the things that would break a sale, like a plan for a different network, or the same vendor twice.

 curl -X PUT https://api.useroutegate.com/v1/vendor-routes/MTN-SME-1GB \
  -H "Authorization: Bearer $DASHBOARD_SESSION" \
  -H "Content-Type: application/json" \
  -d '{
    "steps": [
      { "vendor_plan_id": "01a0d8e3-0000-7000-8000-0000000000b1" },
      { "vendor_plan_id": "01a0d8e3-0000-7000-8000-0000000000c2" }
    ]
  }'

How a sale steps down

With lines then vendors on, a sale is offered to your lines first, ranked by your routing strategy. If a line cannot take it, the next line gets it. If none can, the first vendor in that plan's fallback order gets it, then the second. The retry budget covers lines and vendors together, so a sale does not wander forever.

Each vendor account has its own circuit breaker. A vendor that keeps failing is taken out of the order for a while, on its own, without touching the others or your lines.

The rule that matters most is how a vendor's silence is read:

• A vendor that could not be reached at all, where the request never left, is a temporary failure. The sale moves to the next step straight away. Nothing was sent, so nothing can be sent twice.
• A vendor that took the request and then gave no clear answer is not a failure. The request may well have been delivered. The sale stays pending and Routegate asks that same vendor for the status until it knows, through that same account, even if you pause the account in the meantime.

The second case is the one that costs money elsewhere. Sending a sale to a second vendor while the first may still deliver it is how a customer gets two gigabytes and you pay for both. We would rather a sale wait than guess.

The things your vendors sell that we do not list

A vendor's price list is usually longer than ours. For the bundles you want to sell that our catalogue does not have, you build a vendor-only plan: your own plan, with your own code starting vendor:, made from one to five of your vendor plans in order. It goes through the same API, the same idempotency and the same webhooks as any other sale.

 curl -X POST https://api.useroutegate.com/api/v1/data \
  -H "Authorization: Bearer $ROUTEGATE_API_KEY" \
  -H "Idempotency-Key: ord-00050" \
  -H "Content-Type: application/json" \
  -d '{
    "network": "mtn",
    "product_code": "vendor:mtn-500mb-weekly",
    "destination": "08031234567",
    "client_reference": "ord-00050"
  }'

The transaction that comes back says "sold_as": "vendor_only" and carries the plan as it was when sold, so a report run months later still reads the name you sold it under.

Electricity and cable TV go the same way. Lines never sell bills; a bill goes through your bill vendor plans in order, and the meter or smartcard number can be checked with your own vendors before you sell, so the customer's name is on the screen before anyone pays.

Where the money goes

Routegate never pays your vendor and never holds a balance for one. You fund each vendor account at its own site, exactly as you do now, and each sale it serves is paid from that balance. Routegate charges you only the plan's charges, the same whichever route serves it, or for a vendor-only plan, its vendor-only fee.

In test mode

Test keys never call a vendor. Test mode runs every sale, vendor-only plans and bills included, against the mock, so you can build the whole flow, fallback orders and all, before you connect a single real account.