REST API documentation
LRN routing lookup REST API
Look up the routing number and available carrier information for a North American telephone number at a flat price.

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.
Look up a number
GET /v3/lrn/{number} accepts the destination number in the path. An optional originating number can be supplied as /v3/lrn/{number}/{ani} for origin-dependent information. Use North American digits with the country code where applicable; the examples use reserved fictional numbers.
curl --fail-with-body \
--user "$MULTITEL_API_USERNAME:$MULTITEL_API_PASSWORD" \
--header "Accept: application/json" \
"https://api.multitel.net/v3/lrn/12025550123"curl --fail-with-body \
--user "$MULTITEL_API_USERNAME:$MULTITEL_API_PASSWORD" \
--header "Accept: application/json" \
"https://api.multitel.net/v3/lrn/12025550123/12025550124"Running a lookup with valid credentials is billable. The rate is $0.00025 per lookup: $0.25 per 1,000 or $250 per million. There are no volume discounts. This is a routing-information lookup; it does not place a telephone call.
Read the result
{
"status": {
"code": 200,
"msg": "Success"
},
"response": {
"lrn": "12025550123",
"ported": 0,
"ocn": "",
"lata": "",
"rc": "",
"cost": "$0.00025"
}
}This invented example demonstrates the response shape only; it is not a measured routing result. Check status.code before using response. The cost field is a currency-prefixed string, not a JSON number.
| Field | Meaning |
|---|---|
lrn | Location Routing Number used to identify the routing destination. |
ported | Portability indicator supplied by this lookup: typically 0 or 1. Do not use it as proof of ownership or service eligibility. |
ocn | Operating Company Number, when provided. |
lata | Local Access and Transport Area, when provided. |
rc | Rate center, when provided. |
city, state, lec, lectype, jurisdiction, local | Additional location, carrier or origin-related details when available. They may be absent or blank. |
Do not require every routing field to be present. In particular, toll-free results can omit local rate-center and carrier-code details. A returned LRN is not a real-time guarantee of reachability or a call-quality test.
Use lookups in your routing workflow
- Validate and normalize the requested number before sending it.
- Inspect HTTP and application status. Keep a redacted record of the number, time and result for troubleshooting.
- Use only the fields relevant to your routing rule and handle absent values explicitly.
- Bound retries after an uncertain response. Repeating a lookup can produce another charge; this endpoint has no documented idempotency key.
See the LRN product and flat pricing. The public OpenAPI path includes an ANI segment; the deployed LRN implementation also accepts the shorter request without ANI. lrninfo is a separate operation and should not be substituted for this endpoint.
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.