REST API documentation
Emergency-calling REST APIs
Register a number and service address, follow its activation status, and maintain the record as the location changes.
Choose the API and credential together
Approved Developer & Automation, Business and Communications Provider accounts can integrate enabled services. An individual developer does not need to pretend to be a company. Application SMS/MMS requires the applicable sending approval and registration. Personal & Family service has no customer-accessible messaging-origination API.
| API family | Base URL | Authentication and result |
|---|---|---|
| Communications v3 | https://api.multitel.net/v3 | Approved Basic credentials; eligible provisioned tokens only for operations that support them. JSON status and response. |
| Emergency registration | https://api.multi.tel/emergency | Approved Basic credentials or specifically provisioned bearer access. JSON code, message and data. |
| Portal REST integrations | Host and operation shown in your account’s developer reference | Use that operation’s documented credential, scopes and schema. Browser session requests are a separate surface. |
Set MULTITEL_API_USERNAME and MULTITEL_API_PASSWORD through your server’s secret configuration before using the examples. Never embed them in public browser JavaScript, URLs or source control. Dedicated credentials are managed in API Integration settings.
Read coverage without registering a number
curl --fail-with-body \
--user "$MULTITEL_API_USERNAME:$MULTITEL_API_PASSWORD" \
--header "Accept: application/json" \
"https://api.multi.tel/emergency/coverage?environment=production"https://api.multitel.net/emergency is also supported. Neither emergency base URL contains /v3. Coverage lists international countries, supported number types and prices; North American E911 eligibility is checked during registration.
{
"code": 200,
"message": "",
"environment": "production",
"requestId": "EXAMPLE_REQUEST_ID",
"data": {}
}This illustrates the envelope only. Read each operation’s data schema in the published Emergency API guide.
Register, follow status, then configure calling
- For US/Canada and the other supported North American E911 regions, provide the number, E911 address and required consent acknowledgments. North American E911 is production-only.
- For a supported owned international number, provide either a saved Document reference or the end user’s identity and address. Review the country and number-type requirements first.
- Send one
POST /registrationsrequest. An optionalIdempotency-Keyidentifies a logical mutation; preserve it and the exact payload across retries. - Read
GET /registrations/:number. Inspect lifecycle,pendingandactionRequired; resolve required corrections. Acceptance or pending is not active service. - After activation, configure the correct emergency caller ID and country-specific dialing route. Use the service’s non-emergency verification procedure.
International sandbox registrations are isolated and do not activate real emergency calling. Main-account credentials are required for North American E911; the guide explains the limited international subaccount support.
Handle errors and retries
- Authentication or permission failure
- Check the API credential’s enabled state, permitted service and source-IP restriction. A portal session cookie is not an integration credential.
- Insufficient credit or unmet approval
- Resolve the account balance, sending approval or document requirement before repeating the operation.
- No result
- Handle empty inventory or a missing caller name as an ordinary outcome. Do not assume a syntactically valid number has every service.
- Network timeout or service failure
- Use bounded retries with backoff for reads. For a purchase, send or registration, inspect the operation state first; retrying an accepted request can duplicate a billable action.
Idempotency support belongs to each API family. The Emergency API supports retry keys; that does not make arbitrary v3 requests idempotent. Keep timestamps, returned IDs and redacted responses for support.
Continue with your account’s reference
The signed-in reference filters operations by your permissions and enabled services. Use its exact host, credential type, request fields and response schema. The consoles can execute live operations, including purchases and messages.