Skip to main content

​
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 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

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

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

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). Omit it and the default body, Orbit delivery verification — message body sample, is used.
The response is one poll handle per accepted handset row:
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

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:
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: 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: