Skip to main content

​
Network APIs and the CIBA silent-auth flow

Network APIs are Orbit’s surface for the GSMA Open Gateway / CAMARA family of operator-grade network hooks: identity verification without an OTP, quality-of-service shaping, roaming and SIM-swap events, network slices, and routing of your own IP prefixes. This page explains what the surface exposes and how the client-initiated backchannel authentication (CIBA) flow behind Silent Network Auth works, so you can decide which pieces belong in your integration. Request and response shapes for every endpoint live in the Network APIs reference and are deliberately not repeated here. This page covers the model those endpoints operate on.

​
What Network APIs expose

The developer console groups the CAMARA hooks into these families. Each one is a tenant-scoped surface that reaches the mobile operator directly — none of them sends a message or a call to the subscriber. Everything on the surface is read or control-plane traffic toward the operator — a Number Verification dip, a QoD session, or a prefix announcement never touches outbound voice or SMS paths.

​
The CIBA flow behind Silent Auth

Silent Network Auth answers one question: does the device on this cellular connection hold this phone number? The answer is a network possession proof minted through the client-initiated backchannel authentication (CIBA) flow, and it only works when the request travels over the mobile-data bearer rather than WiFi — that binding is what turns an ordinary token into possession evidence.
  1. The mobile SDK takes the cellular data bearer. The SDK forces the authorization request onto the LTE/5G connection, not WiFi, so the serving operator can bind the session to the SIM. Without this step everything after it is a reachability check, not a possession proof.
  2. The operator mints a network-bound token. The operator’s OpenID Provider runs the CIBA (authorization-code) flow and returns a short-lived OAuth 2.0 access token minted from that data session.
  3. The SDK forwards the token to your backend. The device hands your app the token, and your app posts it to your own backend. The device never carries an Orbit API key.
  4. Your backend dips Silent Auth with the token. Your authenticated backend calls the Number Verification endpoint with the asserted number and the device-bound token; Orbit relays it to the operator’s Number Verification endpoint.
  5. The operator returns the verdict. The operator compares the SIM that minted the token against the asserted number and answers whether the device holds that number.
  6. The verdict resolves fail-closed. Only an explicit network-confirmed match counts as verified. If the number is ineligible, the request ran on WiFi, or the dip errors, the result is unverified and your verification chain falls back to a normal OTP — a flaky dip never strands the user.
The pairing to internalize: cellular data plus a bound token means possession; anything else means fall back.

​
When to use silent-auth vs Verify OTP

Silent Auth and the classic OTP in Verify solve the same problem at different conversion points.
  • Choose Silent Auth when the number sits in a native mobile app where you can run the CIBA flow over the device’s own data connection. It removes the typed-code step at checkout or login, so it usually converts better than an SMS OTP.
  • Choose the OTP path — POST /verify/send with SMS, WhatsApp, voice, email, or another delivery channel — when any of these holds: the session runs on a desktop browser with no cellular bearer, you cannot ship a mobile SDK step on the device, or the operator coverage for silent-auth verdicts is missing for the number’s carrier.
  • Chain them. A Verify session with silent-auth eligible and an OTP channel behind it gets the best of both: the dip either returns instantly or falls back to a deliverable code. The session lifecycle, fallback chain, and events are the same either way — see the verification lifecycle concept.
SIM-swap screening composes with both: run the SIM-swap dip first and reject the auth outright, or let the pre-send SIM-swap check refuse the send before a session exists.

​
Configuration in the developer console

The Network APIs surface lives under Developer → Network APIs in the dashboard. The page first probes whether this deployment has operator credentials; until it does, the operational panels stay behind a roadmap view and the only live action is the early-access registration. When an operator is configured, each panel carries its own controls:
  • Identity tools — one shared E.164 input drives every dip; each tool (Number Verification, SIM Swap, KYC Match, Device Location, Device Status, Age Verification, Scam Signal, Risk Score) is a separate card you trigger per number.
  • Subscriptions (SIM Swap, roaming status) — create a subscription per number; the panel tracks the operator-issued ids created in your session so you can read or delete them.
  • QoD sessions — create requires the device and an application-server IPv4 address; the returned session id drives status reads, extension, and teardown from the same panel.
  • Connectivity insights — a one-shot check of device-to-server network quality with a target IPv4 and a monitoring timestamp.
  • Network slices — book a slice for a device, list active slices, and release them.
  • Prefix failover — register your prefixes, assign failover groups and roles, and watch health status and violation counts.
The CIBA integration guide on the same page is stateless reference material: it renders the step sequence above regardless of operator status, because the client-side half of the flow is yours to build before any operator is reachable.

​
Compliance and tenancy

Controls on this surface are tenant-owned: whether you enroll a number in a SIM-swap or roaming subscription, which QoD profile or slice you book, which prefixes you announce, and how you branch on an unverified verdict are your organization’s decisions, not a platform mandate. Orbit fails closed on the surface itself — with no operator configured, the dips return unverified rather than fabricating a verdict — but it does not impose a policy on how you use the signals. Pair this with your own obligations: silent-auth and the identity dips are possession and attribute signals, not consent. Consent, quiet-hours, and suppression for any messaging you send afterwards stay governed by your tenant’s compliance configuration, exactly as they do for a classic OTP send.

​
Where the how-to lives