Skip to main content

​
Network APIs operator console walkthrough

The one-shot checks in Network signals before you send are ask-and-move-on: a verdict at the moment you request it. The console at Developer → Network APIs is where the stateful loops live — QoD sessions you extend and tear down, monitoring subscriptions you enroll and stop, slice reservations you release, prefix announcements you watch fail over. This guide walks those cards in the order you will meet them. Per-endpoint parameters and response schemas live in the Network APIs reference and are not repeated here. The event-driven API path for subscriptions is covered in Continuous monitoring; this guide is the console view of the same resources.

​
Read the status gate first

Every operator-backed card on the page is gated on one probe:
The console runs the same probe when the page loads and splits on the answer:
  • { "enabled": true } — a GSMA/CAMARA operator is configured for this deployment. The header shows a Live badge and the page renders the operational cards: identity tools, SIM-swap and roaming monitoring, QoD sessions, connectivity insights, network slices, and prefix announcements.
  • { "enabled": false } — no operator is wired yet. The header shows a Coming soon badge and the page renders the capability overview plus an early-access waitlist form instead of the operational cards. Register your interest there, keep your existing fraud screens running, and treat every endpoint on this surface as 503 SERVICE_UNAVAILABLE until the deployment flips (see Fail-soft behavior below).
Two cards render in both states because neither depends on a configured operator: the BYO prefix announcements card (Orbit’s own proxy surface) and the silent-auth walkthrough. If the probe itself is unreachable, the console fails to the waitlist view — it never shows the operational cards without a confirmed operator.

​
QoD sessions: create, extend, tear down

Quality-on-Demand shapes a prioritized data bearer for one device toward one application server. The canonical use is a latency-bound session — emergency voice, field telehealth — where a congested cell would ruin the call. QoD shapes the data path only; it never creates, routes, or ends a call or a message.
1

Create the session before the call starts

In the Quality-on-Demand (QoD) card, fill in:Create session asks the operator to provision the bearer. The button stays disabled until the number, IPv4, and duration validate, so a malformed request never leaves the page.
2

Read the active session card

On success the card flips to the active session view. This is the session list for the page — it shows:
  • Status as a badge: Requested (the operator is still provisioning; the bearer is not live yet), Available (the bearer is live), or Unavailable (the operator could not provision it — a fail-soft outcome, not a clean session).
  • The session ID, the QoS profile, the granted duration, and the started and expires timestamps.
Refresh status re-reads the session from the API; watch a Requested session until it reports Available before you treat the bearer as live.
3

Extend a running session

If the call runs past the granted duration, set Add time (seconds) (1 to 86,400; the field defaults to 600) and press Extend session. The granted window grows by the added seconds; the card re-renders with the new expiry.
4

Tear down when the call ends

Open the session actions menu, choose Delete session, and confirm. Tearing down collapses the live QoS bearer immediately and cannot be undone — restoring priority means requesting a new session. Delete at call end rather than letting every session run to expiry: an idle bearer holding priority is capacity your other sessions cannot use.
Skip QoD when latency does not gate the outcome — bulk messaging, batch analytics, and store-and-forward flows gain nothing from a prioritized bearer.

​
SIM-swap and roaming subscriptions: enroll, read, stop

The SIM Swap monitoring card and the Roaming monitoring card below it operate the continuous subscriptions from Continuous monitoring without curls. Enrollment is per number. Each subscription watches exactly one E.164 number, so a watchlist of high-value accounts is a list of enrollments: enter the number and your notificationUrl (HTTPS only), and enroll once per number. The console is the manual path — a production system that enrolls and reconciles at scale does it through POST /sim-swap/subscriptions and POST /device-roaming-status/subscriptions, exactly as the continuous-monitoring guide walks. After enrolling, the card lists the subscriptions created from the console with the operator’s current status for each — Active, Inactive, or Pending — and re-reads a subscription’s state on demand. The roaming card mirrors the same loop for roaming-on / roaming-off events. Stopping is confirmed, not casual. Each card stops a subscription behind a confirmation dialog; the stop maps to DELETE on the subscription, and the operator stops delivering events once it accepts the teardown. Plan for the short tail of in-flight events the continuous-monitoring guide describes: your receiver must ack and discard events for subscriptions it no longer tracks. Consume the CloudEvents with a production receiver. Every event arrives at your notificationUrl as a CloudEvent carrying your notificationAuthToken as a bearer header. Reuse the existing webhook-consumer pattern — authenticate the bearer, dedupe on the event id in your database, ack fast and decide in a worker — from the production webhook consumer checklist. The continuous-monitoring guide adapts that pattern to this sink with a working receiver.

​
Network slices: list, read, release

The Network Slices card lists your slice bookings with each booking’s current state; select a booking to read its details. Bookings follow the same route family under /network-slices in the reference.
Releasing a reservation is irreversible. The console asks for confirmation before it releases, and once released the reservation is gone — there is no restore, only booking a new reservation. Release at the end of the window that justified the slice (an event, a launch, a test period), not as a routine tidy-up.

​
Prefix failover: read state, watch the reroute, confirm recovery

The Prefix announcements & failover card lists every BYO prefix you have registered, one row per prefix:
  • Prefix and ASN — what you announced and under which autonomous system number.
  • Status — announced (live on the internet), pending validation (registered, not yet announced), or withdrawn (no longer announced).
  • Failover — the failover group the prefix belongs to and its role in that group, the active/standby BGP pairing.
  • Fencing violations — how many times traffic for this prefix breached its fencing policy, with the last breach timestamp on hover.
When traffic re-routes. Prefixes paired in a failover group run active/standby: while the active announcement is healthy, it carries the traffic. If the active’s health checks fail for longer than the prefix’s failure threshold, the standby takes over the announcement and traffic re-routes to it. The status and role columns show the new picture after Refresh. Confirming recovery. After a failover, watch the original active’s status return to announced and its health clear before you consider the event closed, and check the Fencing violations column for breaches during and after the window — traffic that kept flowing outside the policy while the group was converged is a separate problem from the failover itself. Registration (an announcement root, one /22 at most, then child announcements) happens in the same card behind Register, and the card renders its list without firing any registration on load — a reload is a pure read.

​
Fail-soft behavior

Three response shapes reach you from this surface, and only one of them is a verdict:
  • 503 SERVICE_UNAVAILABLE — no operator is configured for the deployment, or the operator leg could not answer. This is “no answer”, never “no swap” and never “not roaming”. A fraud screen that reads a 503 as a clean pass has silently disabled itself.
  • 422 — your request failed validation: a malformed E.164 number, a non-HTTPS notificationUrl, an out-of-range duration. Fix the request and retry; the operator was never consulted.
  • A clean 200 with a verdict — the only response you may act on as an answer.
In the console the split shows up as error toasts: a failed create, extend, or teardown leaves the card’s state unchanged, and an unchanged card is not a verdict either. Build the fallback before you need it — SMS OTP where Silent Auth would have run, your own heuristics where risk:score would have fused, manual review where a subscription would have watched — exactly as Network signals before you send lays out.

​
Tenant-owned controls

These operator signals complement, never replace, your own consent and compliance posture. Continuous monitoring consults the operator’s record about a subscriber over time — that is a processing act your privacy notice and consent capture must cover. Orbit surfaces the network’s verdict to your decision point; it does not own your regulatory obligations. Consent capture, fraud thresholds, and the act decision (allow, review, refuse) are tenant-owned controls — Orbit is the conduit.
Concretely:
  • Consent. Pair enrollment in SIM-swap and roaming monitoring with your existing consent flows (see Consent management and Country compliance requirements).
  • Fail-closed posture. With no operator configured, every endpoint returns 503 and nothing verified ever reads as a clean pass; your fallback path is the operating path until the deployment is enabled.
  • Advisory everything. A swapped verdict, a roaming event, or a slice state never blocks, sends, or routes anything by itself — your policy code applies the verdict against thresholds you set.

​
What’s next