Separate API administration from the SIP call path
IDT Express documents separate sandbox and live HTTPS API environments. The sandbox returns fake data and does not affect the production account; the live environment can create billable number orders. API access uses the account API key plus the secret for the selected environment. Those headers authorize management requests, not SIP registration, digest authentication or source-address trust on the voice path.
Preserve API environment, request ID, DID, trunk-group ID, default flag, ring type, PoP, switch targets and production account as distinct records. A 200 or 201 response proves only that management request. A 403, 422 or 429 belongs to the API boundary and is not a SIP response from an attempted call.
Documented service facts
Reviewed 2026-10-23. Compare SIP trunk services →
SIP authentication
Not verifiedThe API key and environment-specific API secret authorize HTTPS management calls; they are not SIP credentials. The reviewed public sources still do not publish one universal outbound digest realm, registrar, secret lifecycle or source-address rule. Preserve API and SIP trust as separate account records.
SIP registration
Not verifiedThe public API defines inbound trunk groups as PoP plus IPv4 switch targets and does not establish a universal REGISTER workflow. It also does not define every account's outbound peer model. Use the production turn-up record rather than inventing a registrar, realm or template.
Inbound delivery
DocumentedEach active DID is assigned to a trunk group. New DIDs begin on the default group, explicit assignment can move them, deleted groups move their DIDs to the default, and the default can be used as a fallback. Ring type, PoP, switch targets, source admission, PBX match and media remain separate evidence.
Routing and failover
Not verifiedFor a trunk group, simultaneous sends to every switch and selects the first answer; sequential begins with the first ordered switch and rolls only when it is unreachable. Multiple stored targets do not prove the trigger, cancellation behavior, recovery or established-call survival.
Number and regional availability
DocumentedThe current product page publishes a country-by-country SIP-trunking availability table, while the API exposes country, region and number browsing and ordering for enabled accounts. A listed country does not establish current inventory, portability, identity rights or regulatory eligibility for a particular customer and number type.
Audio codecs
DocumentedThe inbound reference lists G.711 A-law, G.711 mu-law, G.729A, G.729AB and G.723. The list is capability evidence, not proof of the negotiated payload, packetization, DTMF, transcoding, two-way decoded audio or an account result.
T.38 fax
DocumentedIDT Express states that T.38 is supported but explicitly says it cannot offer guarantees. Preserve the PBX or gateway, remote endpoint, negotiated switchover, page profile and delivery evidence for the intended route; the capability statement is not a successful fax result.
Signaling and media encryption
Not verifiedThe reviewed public product and API sources do not define a customer SIP TLS hostname, certificate-validation procedure, SRTP profile or downgrade policy. HTTPS protection for the management API and a private provider backbone do not establish encryption of the PBX-facing SIP signaling or RTP media leg.
Concurrent calls and call starts
Not verifiedIDT Express advertises unlimited channels and high calls-per-second limits but does not publish one numeric account CPS or concurrency value on the reviewed pages. Contracted channels, active calls, call starts, account throttles, PBX resources and bandwidth remain different quantities that require dated account evidence.
Emergency calling
Not verifiedThe reviewed SIP-trunking, API and provider pages do not establish emergency-service countries, address registration, caller-identity requirements, callback handling or an approved test procedure for this service. Do not infer emergency access from DID availability or ordinary outbound termination.
Pricing model
Not verifiedIDT Express describes pay-as-you-go voice and account rate information, but route, DID, porting, feature, minimum-commitment, tax and support terms remain time- and account-specific. Use a dated portal export or quote; public promotional credits and market-language are not a complete production cost model.
Administration and support
DocumentedThe portal owns API credentials. Sandbox data is fake and does not affect production; live calls can create billable number orders. API request IDs, DID assignment, default group, ring type, PoP and ordered switches are management evidence only and do not prove PBX routing or a completed call.
SMS and MMS
Not verifiedIDT Express advertises a separate SMS platform and APIs. The reviewed sources do not establish that every SIP-trunk DID is messaging-enabled or that voice ordering grants messaging registration, sender identity, routing or pricing. Treat messaging as a separately ordered and verified service.
Trace every DID to its effective trunk group
The API says each active number is assigned to a trunk group. New DIDs start on the account default trunk group, an explicitly assigned DID can move to another group, and deleting a non-default group moves its DIDs to the default. The default also acts as fallback when IDT Express cannot determine the intended route.
Record the exact DID, explicit assignment, current default, group ID and last mutation before reading the PBX dialplan. A correctly formed trunk group does not prove that the failed DID points to it. A route that unexpectedly reaches the default group is assignment evidence, not proof that the first switch or PBX route is healthy.
Keep simultaneous and sequential switch behavior exact
A trunk group contains IPv4 switch addresses and ports. IDT Express documents simultaneous routing as sending a call to every switch in the array and selecting the first answer. Sequential routing begins with the first array entry and rolls to the next only when the earlier switch is unreachable. Array order therefore matters for sequential groups, while parallel answers and cancellation behavior matter for simultaneous groups.
Preserve ring type, ordered switch array, destination port, each INVITE, response and selected dialog. Do not describe a busy, rejection, timeout or application response as unreachable without evidence that it satisfies the provider trigger. Do not infer established-call survival from a new-call routing feature.
Bind the selected PoP to the documented inbound source
The current API reference exposes US, UK and HK PoP choices and publishes different inbound source addresses for each. The selected PoP, expected signaling source, firewall receipt, destination switch and PBX route are separate checkpoints. A nearby PoP recommendation is a planning input, not measured latency or media quality for one deployment.
Allow only the current first-party sources required by the ordered service and verify the source address actually observed. A correct allowlist does not prove DID assignment, switch selection or Request-URI handling. Conversely, a missing packet at the PBX does not prove provider loss until edge capture and return routing are correlated.
Treat codec and fax lists as capability evidence
The inbound configuration reference lists G.711 A-law, G.711 mu-law, G.729A, G.729AB and G.723, and says T.38 is supported without a guarantee. These are interface capability statements, not evidence of the SDP answer, packetization, DTMF method, transcoding path, decoded audio or delivered fax pages.
For one authorized call, retain Call-ID, offer, answer, selected payload, media addresses and packets in both directions. For fax, also retain gateway mode, switchover, remote endpoint, page profile and delivery report. Signaling success, provider receipt and two-way intelligible media remain separate outcomes.
Keep unresolved account controls out of the template
The reviewed pages advertise capacity, points of presence, redundant routing, number coverage, support and separate messaging, but do not publish one universal outbound peer model, SIP registrar, digest realm, customer TLS hostname, SRTP profile, emergency workflow, account CPS value or concurrency entitlement. API HTTPS and a private backbone do not establish encryption on the PBX-facing SIP or RTP leg.
Obtain the current turn-up record and account evidence for outbound identity, authentication, transport, capacity, emergency service, pricing, availability, compatibility and support. No IDT Express account, credential, order, DID, trunk group, switch, packet, PBX, call, media stream, fax or failover event was inspected or tested.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IDT Express DID and trunk-group API ↗
- IDT Express SIP Trunking ↗
- IDT Express SIP-trunk provider services ↗
- IDT Express DID Numbers ↗
- IDT Express DID setup troubleshooting ↗
- IDT Express SIP trunk security ↗
- IDT Express voice termination ↗
- IDT Express guide to SIP trunking ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.