> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Network APIs and the CIBA silent-auth flow > What Orbit's Network APIs expose (GSMA Open Gateway / CAMARA identity, QoD, roaming, slicing, and prefix hooks), how the CIBA data-bearer Silent Network Auth flow proves number possession without an SMS OTP, and how to choose between silent-auth and a classic OTP. # 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](/api-reference/network-apis) 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. | Family | What it does | | --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Silent Auth (Number Verification)** | Proves the device on the network holds a given phone number, without an SMS OTP. The possession proof rides the CIBA flow described below, and the verdict is interpreted fail-closed. | | **Identity tools** | One-shot dips: SIM-swap detection (reject the auth attempt if the SIM changed recently), KYC match (compare a name and address claim against the operator's billing record), device location and status, age verification, scam signal, and a fused risk score. | | **SIM Swap and roaming status subscriptions** | Stateful, operator-issued event subscriptions. Create a subscription for a number, receive events when the SIM is swapped or the device starts or stops roaming, and read or delete the subscription by its id. | | **Quality on Demand (QoD)** | Shapes one device's data bearer on demand: request a low-latency or high-throughput session toward your application server, poll its status, extend it, and tear it down. The returned `sessionId` addresses every later operation. | | **Connectivity insights** | A read-only network-quality check for a device toward an application server — congestion status and throughput for the path, as a diagnostic before you commit to a QoD session. | | **Network slices** | Books and releases a dedicated data slice for a device. A slice shapes data transport only; it never creates voice or SMS capacity. | | **Prefix failover** | Bring-your-own-IP announcements: register your prefixes, group them for failover, and track health and violation counts. This is routing plumbing for your own address space. | 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](/verify/overview) 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](/concepts/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 * [Network APIs reference](/api-reference/network-apis) — every endpoint with request and response shapes. * [Verify overview](/verify/overview) — the classic OTP send and check path to fall back to. * [Verification session lifecycle](/concepts/verification-lifecycle) — the session model, fallback engine, and events that both silent-auth and OTP sessions share.