> ## 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. # Sender-ID live-number testing > Verify a sender ID's real deliverability into a destination MCC/MNC before a campaign ships, using the TelQ live-number-testing endpoints and the dashboard Delivery Test page. # Sender-ID live-number testing Before a high-volume campaign ships, the riskiest unknown is not your copy or your audience — it is whether your sender ID actually delivers into the destination network. A route that filters your alphanumeric sender silently drops the entire campaign. Live-number testing (LNT) answers that question with one real SMS, delivered through a chosen supplier to a test handset on the destination network, before you send a single production message. TelQ, the delivery-testing provider Orbit integrates with, keeps test handsets on live carrier networks worldwide. When you submit a test, TelQ sends the SMS and the handset's reply confirms the sender ID arrived — a carrier-grade yes/no on the route your campaign is about to depend on. That is the pre-flight this guide walks through: four API calls between "route candidate" and "audience launch," plus the constraints, error codes, and cost discipline that come with burning carrier-side test budget. All endpoints below are rooted at `https://api.orbit.devotel.io/api/v1/testing`. *** ## Prerequisites The LNT surface is gated deliberately, because every submission bills through the chosen supplier: * **TelQ integration configured.** Check with `GET /testing/status` — it returns `{ "configured": true }` (or `false`) without triggering anything billable. * **Role: owner, admin, or developer.** Submission and supplier listing are rejected for other roles. * **Supplier resolution.** Every test exits through a supplier — either the organization default (`DEVOTEL_TELQ_DEFAULT_SUPPLIER_ID`) or a per-network override for the destination. `GET /suppliers` lists the suppliers available to choose from. If neither resolves, submission returns 503 (see [Error surface](#error-surface) below). * **Rate limit: 10 submissions per minute.** Poll endpoints (`/status`, `/networks`, `/suppliers`, result polling) are standard authenticated reads; only `POST /sender-id-test` is capped. Design pre-flight scripts to a few deliberate tests per run, not a sweep of every network. *** ## The four-call workflow The dashboard **Delivery Test** page runs exactly this sequence, so automating it is the same four calls: ### 1. Confirm the integration ```bash theme={null} curl "https://api.orbit.devotel.io/api/v1/testing/status" \ -H "Authorization: Bearer $ORBIT_API_KEY" ``` ```json theme={null} { "data": { "configured": true } } ``` If `configured` is `false`, contact support before doing anything else — every other step returns an empty or null payload rather than a usable test. ### 2. Pick the destination network ```bash theme={null} curl "https://api.orbit.devotel.io/api/v1/testing/networks?mcc=262&mnc=01" \ -H "Authorization: Bearer $ORBIT_API_KEY" ``` Both query params are optional; supply an MCC/MNC you intend to send into and TelQ returns only networks it can reach there. Call it once and reuse the list across tests. ### 3. Submit the test ```bash theme={null} curl -X POST "https://api.orbit.devotel.io/api/v1/testing/sender-id-test" \ -H "Authorization: Bearer $ORBIT_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "sender_id": "ACME", "mcc": "262", "mnc": "01" }' ``` `sender_id` (1–15 characters), `mcc`, and `mnc` are required. Two optional fields tune the test: * `ported_from_mnc` — if the destination subscriber was ported from another network code, pass the original MNC so the handset match routes correctly. * `text` — your own body, subject to TelQ's stop-word constraint ([below](#message-text-stop-words)). Omit it and the default body, `Orbit delivery verification — message body sample`, is used. The response is one poll handle per accepted handset row: ```json theme={null} { "data": [ { "id": 88132491, "phoneNumber": "+4915112345678", "testIdText": "3f9a1c" } ] } ``` Keep `id`; that is the poll handle for step 4. `testIdText` is the token the handset is expected to have echoed back. ### 4. Poll the result ```bash theme={null} curl "https://api.orbit.devotel.io/api/v1/testing/sender-id-test/88132491" \ -H "Authorization: Bearer $ORBIT_API_KEY" ``` Write the poller the way the dashboard does: poll on a fixed interval and treat an error response as "not ready yet," not a verdict. *** ## Message text: stop-words TelQ rejects a test body containing any of **test**, **fraud**, **spam**, or **phish** — matched case-insensitively at word boundaries. Orbit applies the same validation before the round trip, so a rejected word comes back as HTTP 422 rather than after you have burned the per-test cost. The response tells you exactly which word triggered it: ```json theme={null} { "error": { "code": "VALIDATION_ERROR", "status": 422, "details": { "field": "text", "stop_word": "test" } } } ``` Either omit `text` and use the default body quoted above, or screen your own body against the same four words before sending. If your campaign copy must use one of those words, an LNT probe is not the tool for content verification — keep probes to generic body text. *** ## Error surface Failures come back with specific, actionable codes — not opaque 500s. Design your script against these: | HTTP | `code` | Meaning | | ---- | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 502 | `TELQ_NETWORKS_UNAVAILABLE` | TelQ could not serve the network list right now. Retry in a moment. | | 502 | `TELQ_SUBMISSION_FAILED` | The provider refused the test (supplier offline, or no reachable handset for this MCC/MNC). Retry or pick another supplier. | | 502 | `TELQ_RESULT_UNAVAILABLE` | The result poll failed upstream. Treat as "not ready," re-poll. | | 502 | `TELQ_SUPPLIER_LOOKUP_FAILED` | Supplier resolution hit a transient error. Retry. | | 503 | `TELQ_SUPPLIER_NOT_CONFIGURED` | A config gap, not a blip: no default supplier and no per-network override resolves for this destination. Set the organization default supplier setting or a per-network override, then retry. | | 422 | `VALIDATION_ERROR` | Body or query shape problem, or a stop-word in `text` (`details.stop_word` names the word). Fix before retrying. | Only `503 TELQ_SUPPLIER_NOT_CONFIGURED` is non-transient by design; every other code above is safe to retry after a short backoff. *** ## Audit trail and dose discipline Every successful submission writes an audit event naming the sender ID, the MCC/MNC, and the supplier the test exited through, so a compliance review can see the pre-flight ran before the campaign went out. The same discipline accounts for cost: each accepted test is a billable outbound SMS through the supplier. Pre-flight discipline is "run the minimum set of tests that covers the campaign's routing surface," not "run everything." A two-network check before a high-volume send is the right dose; a 200-network sweep before a five-minute campaign is not. *** ## Where LNT sits in the pre-campaign checklist Wire the probe between audience build and launch, next to the other pre-flight steps you already run (DNC scrub, template review): 1. Build the audience and the sender IDs it will send from. 2. Identify the campaign's top destination MCC/MNC pairs from the segment profile — usually one country, one to three carrier networks. 3. Run one LNT per sender ID against those pairs. For most campaigns a single sender ID and one or two destination networks is the whole surface. 4. Launch only if every probe returned delivered. If a sender ID fails its LNT, fix the route or the sender registration **before** the campaign discovers it at scale. The dashboard Delivery Test page does steps 1–4 interactively; the four endpoints above run the same check from CI or a launch-checklist script. *** See also: * [Go-live checklist](/guides/go-live-checklist) — the launch-day list this probe belongs on. * [Send and receive messages](/guides/send-receive-messages) — the production send surface the pre-flight protects. * [API reference](/api-reference) — full request/response schemas for the endpoints used here.