REST API documentation

Make your first MultiTEL API request

Start with a read-only request, understand the response, then choose the reference for the service you want to build.

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 familyBase URLAuthentication and result
Communications v3https://api.multitel.net/v3Approved Basic credentials; eligible provisioned tokens only for operations that support them. JSON status and response.
Emergency registrationhttps://api.multi.tel/emergencyApproved Basic credentials or specifically provisioned bearer access. JSON code, message and data.
Portal REST integrationsHost and operation shown in your account’s developer referenceUse 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.

First request: read your balance

This read does not purchase a service or originate a call or message.

curl --fail-with-body \
  --user "$MULTITEL_API_USERNAME:$MULTITEL_API_PASSWORD" \
  --header "Accept: application/json" \
  "https://api.multitel.net/v3/getbalance"

The communications v3 API returns an application result inside the JSON body. Check the HTTP status and status.code before reading response; a rejected request may have no response object. Code values can be strings or numbers.

{
  "status": {
    "code": 200,
    "msg": ""
  },
  "response": {
    "balance": "25.0000",
    "currency": "USD",
    "terms": "Prepaid"
  }
}

This is a fictional example, not an account balance. Treat monetary values as decimal amounts. Keep the server’s response message when diagnosing a rejected request, with credentials removed.

Use billing data correctly

The balance response contains the current balance, currency and payment terms. It does not give the cost of a future call or a complete invoice. Use the matching rate and usage operations for those questions. Existing numbers can have different plans from today’s catalogue.

Choose your next integration

LRN routing lookup REST API

Look up the routing number and available carrier information for a North American telephone number at a flat price.

Read the integration guide →

Phone-number REST APIs

Discover available countries and numbers, inspect the complete offer, and manage the numbers you own.

Read the integration guide →

SMS & MMS REST APIs

Send approved application messages and handle acceptance, delivery events, segmentation and charges.

Read the integration guide →

Emergency-calling REST APIs

Register a number and service address, follow its activation status, and maintain the record as the location changes.

Read the integration guide →

Account & billing REST APIs

Read the balance and billing information available to your approved integration.

Read the integration guide →

CNAM and routing lookups

Read caller names, understand lookup tiers and use number-routing information.

CNAM REST reference →

LRN request and pricing →

Hosted PBX

Start with available service plans and the tenant you intend to configure.

Hosted PBX service-plan API →

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.