> ## 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 operator console walkthrough

> Operate the stateful Network APIs loops from the console: read the status gate, run QoD sessions through create, extend, and teardown, enroll and stop SIM-swap and roaming subscriptions, release slice reservations, and read prefix failover state.

# Network APIs operator console walkthrough

The one-shot checks in [Network signals before you send](https://docs.orbit.devotel.io/guides/network-signals-open-gateway.md) 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](https://docs.orbit.devotel.io/api-reference/network-apis.md) and are not repeated here. The event-driven API path for subscriptions is covered in [Continuous monitoring](https://docs.orbit.devotel.io/guides/network-apis-continuous-monitoring.md); 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:

```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/numbers/network-apis/status" \
  -H "X-API-Key: $ORBIT_API_KEY"
```

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](#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:

| Field | Example | Notes |
| - | - | - |
| Device number (E.164) | `+14155550100` | The handset whose data bearer gets priority. |
| Application server IPv4 | `203.0.113.10` | Dotted-quad; the bearer is shaped toward this address. |
| Application server IPv6 | `2001:db8::10` | Optional. |
| QoS profile | `QOS_E` | The console default; a low-latency profile. |
| Duration (seconds) | `3600` | 1 to 86,400. |

**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.

```bash theme={null}
curl -X POST "https://api.orbit.devotel.io/api/v1/numbers/network-apis/qod-sessions/qod_abc123/extend" \
  -H "X-API-Key: $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "requestedAdditionalDuration": 1800 }'
```

**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.

```bash theme={null}
curl -X DELETE "https://api.orbit.devotel.io/api/v1/numbers/network-apis/qod-sessions/qod_abc123" \
  -H "X-API-Key: $ORBIT_API_KEY"
```

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](https://docs.orbit.devotel.io/guides/network-apis-continuous-monitoring.md) 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](https://docs.orbit.devotel.io/guides/webhook-consumer-production-checklist.md). 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](https://docs.orbit.devotel.io/api-reference/network-apis.md).

> [!WARNING]
>
> 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](https://docs.orbit.devotel.io/guides/network-signals-open-gateway.md) lays out.

## Tenant-owned controls

> [!WARNING]
>
> 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](https://docs.orbit.devotel.io/compliance/consent-management.md) and [Country compliance requirements](https://docs.orbit.devotel.io/compliance/country-requirements.md)).
* **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

* [Network signals before you send](https://docs.orbit.devotel.io/guides/network-signals-open-gateway.md) — the point-in-time checks these consoles complement.
* [Continuous monitoring: SIM-swap and roaming subscriptions](https://docs.orbit.devotel.io/guides/network-apis-continuous-monitoring.md) — the API-first path for enrollment, teardown, and CloudEvent consumption.
* [Production webhook consumer checklist](https://docs.orbit.devotel.io/guides/webhook-consumer-production-checklist.md) — the receiver pattern every `notificationUrl` sink should follow.
* [Network APIs reference](https://docs.orbit.devotel.io/api-reference/network-apis.md) — every endpoint's parameters, response schema, and error contract.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.