Separate the management API from the SIP interconnect
IDT Express documents an HTTPS API for DID coverage, ordering and trunk-group administration. API access uses an account API key plus an environment-specific secret. Those headers authorize the management API; they are not evidence of SIP digest authentication, registration or source-address authorization on the voice path.
Record the portal account, API environment, trunk-group object, ordered SIP peer model, signaling addresses, transport, identity and PBX endpoint separately. The API sandbox uses fake data and cannot change production, while the live environment can create billable orders. A successful sandbox or live API response does not establish that a PBX accepted an INVITE or completed a call.
Documented service facts
Reviewed 2026-10-06. Compare SIP trunk services →
SIP authentication
Not verifiedThe public API documentation defines API-key and environment-specific API-secret headers for DID and trunk-group administration. Those HTTPS credentials are not SIP credentials. The reviewed public sources do not publish one universal digest realm, username, secret lifecycle or source-address authorization rule for the voice interconnect; obtain the account turn-up record.
SIP registration
Not verifiedThe reviewed public pages establish SIP interconnection and regional inbound source addresses but do not state that every account registers, uses static IP authorization or follows one registrar workflow. Preserve the ordered peer model, signaling addresses, transport and identity rules from the account's turn-up material.
Inbound delivery
DocumentedThe API supports DID inventory and trunk groups and publishes different inbound source addresses for the US, Hong Kong and UK points of presence. Number ownership, selected trunk group, permitted source, delivered called identity, PBX match and downstream destination remain separate evidence states.
Routing and failover
Not verifiedIDT Express advertises redundant call routing, multiple points of presence and a private IP backbone. The reviewed public sources do not disclose the account's route order, retryable responses, timers, alternate destination, restoration behavior or treatment of established calls. Treat those as turn-up and approved acceptance-test inputs rather than inferred resilience.
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 configuration reference lists G.711 A-law, G.711 mu-law, G.729A, G.729AB and G.723. The list is an interface capability, not proof of the SDP answer, packetization, transcoding path, received DTMF or two-way decoded audio on an account.
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 manages API credentials and the API separates fake-data sandbox operations from live operations that can order billable numbers. It exposes DID coverage, orders and trunk groups; portal reporting, anti-hack controls and global support are separately advertised. A successful API response does not establish 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.
Bind inbound delivery to the selected point of presence
The first-party API reference publishes distinct inbound source addresses for US, Hong Kong and UK points of presence and associates DIDs with trunk groups. Preserve the assigned number, selected trunk group, expected regional source, firewall rule, delivered Request-URI and identity, PBX match and downstream route as separate evidence.
The public sources do not state that every service uses registration or one universal authentication method. Do not import a generic registrar, realm or credential template. Use the account turn-up record, restrict access to documented sources and confirm inbound and outbound identity independently.
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. It also says T.38 is supported while explicitly declining a guarantee. Those statements are narrower than a negotiated result. Capture the actual offer and answer, endpoints, payloads, packetization and decoded audio for authorized calls.
For fax, preserve gateway mode, remote endpoint, switchover, page profile and delivery report. Do not turn a T.38 listing into a page-delivery promise. The public pages also do not provide one numeric account concurrency or calls-per-second limit, so contracted capacity, active calls, call starts, PBX channels and bandwidth remain separate.
Convert resilience language into testable controls
IDT Express advertises redundant call routing, points of presence, a private IP backbone and scalable capacity. Those statements do not disclose the account's route order, retryable responses, timers, alternate destination, restoration process or established-call behavior. Record each ordered control and test approved new-call failure cases without presenting provider architecture as customer-edge survival.
The reviewed public sources also do not define customer-facing SIP TLS and SRTP policy. API HTTPS, network redundancy and a private backbone do not prove that the PBX-facing signaling or media leg is encrypted. Require the exact SIP transport, certificate and media terms when protected calling is in scope.
Keep availability, emergency service and messaging account-specific
The current product page has a country availability table and the API can browse enabled DID coverage. A listed country does not establish current inventory, portability, number rights or regulatory eligibility for an account. Use a dated order or portal result for the exact country and number type.
The reviewed sources do not establish emergency-service coverage, address registration, callback behavior or an approved test procedure for the trunk. They advertise messaging through a separate SMS platform and APIs, which does not make every voice DID messaging-enabled. Confirm emergency, messaging, pricing, fraud controls and support terms as separate services. No account, API credential, order, DID, trunk group, PBX, peer, route, call, media stream, fax, failover, emergency workflow, price, availability or support response was inspected or tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IDT Express SIP Trunking ↗
- IDT Express DID and trunk-group API ↗
- IDT Express SIP-trunk provider services ↗
- IDT Express voice termination ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.