3 September 2026 · 8 min read · recloud engineering

NBN integration for RSPs: automating serviceability to activation

Every Australian RSP builds the same machine sooner or later: take an address, qualify it, place a wholesale order, track it to activation, then light the service up in the network and start billing. Done manually, each step is a swivel-chair job with a different portal. Done properly, it's one pipeline — and the difference shows up directly in time-to-connect and support load.

Serviceability: qualify once, answer fast

The serviceability check is the front door of your sign-up funnel, so it has to be fast and honest. The pattern that works: an internal qualification service that fronts the wholesale APIs, normalises the answer (technology type, speed tiers available, CPE requirements, known copper/co-existence caveats) and caches aggressively with a sane TTL. Your web funnel, sales tooling and support desk all ask your service, and your service decides when to go upstream.

GET /qualify?address_id=LOC000012345678
{
  "serviceable": true,
  "technology": "FTTP",
  "speed_tiers": ["100/20", "250/25", "1000/50"],
  "appointment_required": false
}

Normalising matters because you will end up multi-wholesaler — NBN plus at least one alternative network — and everything downstream should be indifferent to whose fibre it is.

The order is a state machine. Model it as one.

A wholesale order passes through a long series of states — acknowledged, in progress, appointment scheduled, held, completed — with human-dependent branches (missed appointments, incorrect premises data, held orders awaiting documents). Model this as an explicit state machine with an Order record as the system of record on your side, updated from status webhooks where offered and polling where not:

Every transition is stored with a timestamp — your time-to-connect analytics fall out for free.
Stuck states page a human with context: order, state, age, last wholesale response.
Customer notifications hang off transitions, so the subscriber hears "appointment booked for Tuesday" from you before they hear it from a technician.

Error handling is the product

The happy path is a day of work. The value is in the other paths: address mismatches, rejected orders, appointments that fail, orders that complete upstream but never activate in your network. Two rules we build into every integration:

Idempotency everywhere. Wholesale APIs time out; your pipeline must be able to retry any step without double-ordering. Key every request on your own order reference.
Reconciliation as a scheduled job. Nightly, compare your view of active services against the wholesaler's billing/service reports. Drift means silent money loss in one direction or angry customers in the other.

Close the loop: activation into the network

The most commonly missed automation is the last one. When the wholesale order completes, the service should provision itself: subscriber created in RADIUS with the right speed profile, session limits set, billing started only on first successful authentication — not on order completion. That last rule alone removes a whole category of "billed but never connected" complaints. If your access is on your own BNG, this is a couple of API calls into your AAA and billing stack; we covered the AAA side in the RADIUS article.

What good looks like

A qualified address to an in-flight wholesale order in under a minute, no human hands. Order state visible to support without opening a wholesale portal. Activation to first session measured in minutes. RSPs running this shape of pipeline consistently see connect times well under the industry average — and a support queue that talks about service, not order status.