> ## 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. # TelQ live-number testing model — the sender-ID deliverability probe > The model behind sender-ID live-number testing (LNT): what a supplier is and why tenants never pick one directly, the one-test lifecycle between status check and poll, the three-tier supplier-resolution chain, the in-band stop-word gate, and which failures are transient versus a configuration gap you must close. # TelQ live-number testing model Live-number testing (LNT) answers one question before a campaign ships: **does my sender ID actually deliver into this destination network?** The probe is one real SMS, dispatched through a supplier to real test handsets on the destination carrier, with the handset's reply as a carrier-grade yes/no. [Sender-ID live-number testing](/guides/telq-live-number-testing) is the four-call procedure; this page is the model behind it — the lifecycle a single test moves through, how the supplier it exits through is resolved, and what each failure class means. Read this first; the guide assumes it. ## Suppliers, and why tenants never pick one directly TelQ, the delivery-testing provider, keeps test handsets on live carrier networks. Every SMS it fires at those handsets travels over one of the telecom suppliers TelQ holds agreements with — TelQ's own upstream carriers, not Orbit's production routing. The supplier is the exit leg for the probe: it decides which route your sender ID is exercised on, so the result you poll reflects what your campaign would experience on that route. Your request carries sender ID and destination MCC/MNC — never a supplier. Three reasons: 1. **The supplier is an operator decision.** Suppliers differ in cost per test, coverage, and quality; which supplier serves which destination network is a platform-commercial and routing decision, not per-send input. 2. **The test would stop testing the real thing.** A tenant-chosen supplier would let you probe a route your campaign doesn't use, and the result would not predict delivery. 3. **Every test bills.** An accepted test is one billable outbound SMS through the resolved supplier. Keeping selection platform-owned keeps the only supplier billable through your plan one, per network. So the request names *which destination* to probe; the platform resolves *which exit leg* the probe takes. ## The one-test lifecycle: status → network → submit → poll The five-endpoint surface under `/api/v1/testing` moves one test through four stages: | Stage | Endpoint | What it actually does | | - | - | - | | 1. Status check | `GET /testing/status` | Answers `{ "configured": true \| false }` — is the TelQ integration wired at all. Never billable, never leaves the platform. | | 2. Network discovery | `GET /testing/networks?mcc=…&mnc=…` | Returns the live networks TelQ can probe, filtered by the MCC/MNC you intend to send into. The MCC/MNC pair you find here is the identifier the submit call carries. | | 3. Submit | `POST /testing/sender-id-test` with `sender_id`, `mcc`, `mnc` (plus optional `ported_from_mnc`, `text`) | Resolves the supplier, asks TelQ to dispatch the SMS to its test handsets, and returns one poll handle per accepted handset row: `{ id, phoneNumber, testIdText }`. The step where the billable SMS is sent, so the rate limit and role gate attach here. | | 4. Poll result | `GET /testing/sender-id-test/:testId` | Returns the current result for one poll `id`. **Poll-until-result is the contract**: this endpoint answers the latest known state, and a probe that has not landed yet comes back as an error — "not ready," not a verdict. Re-poll on a fixed interval until a result arrives. | After a successful submit, the lifecycle lives entirely in stage 4: `id` is the poll handle from the submit response, one per handset row TelQ accepted. `testIdText` is the expected-echo token — placed into the SMS ({TEST_ID_TEXT} placeholder) so the token itself travels in the body, and TelQ's matcher confirms the handset echoed exactly that token back. That is how "the sender ID arrived" is proven: not by the SMS being accepted upstream, but by the destination handset echoing the per-test token. Your poller only needs `id`; the echo matching is TelQ-side. Until the poll returns a result, the test is open. A test that never lands means the route genuinely failed to deliver your sender ID into the destination network — the pre-flight answer you burn a billable SMS to get. ## The supplier-resolution chain — three tiers, first match wins Every submit resolves its supplier server-side, in this order: 1. **Per-network override** — a `telq_route:{mccmnc}` routing entry set by the platform operator for the destination's concatenated MCC+MNC. 2. **Global default** — the `telq_default_supplier` entry, one supplier for everything without an override. 3. **Bootstrap fallback** — the operator-configured environment default, kept so the surface works before any routing entries exist. First match wins; tiers consulted in order, never mixed. Per-network overrides exist for corridors where the global default is wrong — a region where one supplier's coverage is materially better. The resolution either finds a supplier or returns `503 TELQ_SUPPLIER_NOT_CONFIGURED`; it never silently picks one, and never prices uncertainty into the request. `GET /testing/suppliers` (owner/admin/developer) lists the supplier IDs overrides reference. ## Gating and billing posture Every accepted test is one billable outbound SMS through the resolved supplier, so the surface is gated rather than open: * **Role gate** — submission and supplier listing are rejected unless the caller is an owner, admin, or developer. * **Rate limit** — `POST /sender-id-test` is capped at 10 submissions per minute. Poll endpoints are ordinary authenticated reads; only the billable stage is capped. Design pre-flight scripts to a few deliberate tests per run, not a sweep of every reachable network. * **Audit event per submission** — every successful submit writes an audit event naming the sender ID, the destination MCC/MNC, and the supplier the test exited through. The pre-flight is provable after the campaign goes out, and the three facts are enough to reconstruct which route was probed and on whose nickel. Dose discipline: run the minimum set of tests that covers the campaign routing surface — typically one or two sender IDs against the destination's one to three carrier networks. ## The stop-word gate TelQ rejects a test body containing any of **test**, **fraud**, **spam**, or **phish** — matched case-insensitively at word boundaries. Orbit applies the same check before any TelQ round trip, so a rejected word returns a clean `422 VALIDATION_ERROR` with `details.stop_word` naming the offending word, instead of burning the per-test cost on a round trip guaranteed to fail. The in-band validation is defense-in-depth, not a preference: the default body passes, but tenants on a developer-role surface can override the body to anything, so the check has to live at the request boundary too. If campaign copy must use one of these words, a deliverability probe is not a content-verification tool — keep probes to generic body text or the default `Orbit delivery verification — message body sample`. ## Error vocabulary as conceptual state The surface uses distinct families deliberately: | HTTP | `code` family | State it represents | Who owns the resolution | | - | - | - | - | | 422 | `VALIDATION_ERROR` | **Request-shape failure** — bad body/query, or a stop-word in `text` (the `details.stop_word` field names it). | You. Fix the request; retry only after fixing. | | 502 | `TELQ_NETWORKS_UNAVAILABLE`, `TELQ_SUBMISSION_FAILED`, `TELQ_RESULT_UNAVAILABLE`, `TELQ_SUPPLIER_LOOKUP_FAILED` | **Transient upstream** — a TelQ-side timeout, 5xx, or unreachable provider. Retry-safe by design. | The provider. Retry with a short backoff; pollers treat `TELQ_RESULT_UNAVAILABLE` as "not ready." | | 503 | `TELQ_SUPPLIER_NOT_CONFIGURED` | **Configuration gap** — the resolution chain found no override, no global default, and no bootstrap fallback. Retrying changes nothing. | The operator. Set the default or add a per-network override, then retry. | The 502/503 line is the point: a 502 means *wait*, a 503 means *configure*, a 422 means *fix your request*. Only the 503 family is non-transient by design. ## Boundaries and See also * If the question is **which sender an outbound message goes out from**, that is [Sender resolution](/concepts/sender-resolution) — the outbound chain LNT probes before shipping to production traffic. * The four-call procedure lives on the [guide](/guides/telq-live-number-testing); request/response schemas live in the [API reference](/api-reference/endpoints/testing). * For a launch-day ordering, see the [Go-live checklist](/guides/go-live-checklist); production sending lands in [Send and receive messages](/guides/send-receive-messages). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.