Before you build a DialNexa API client
- Create an API key in Settings > API Keys.
- Use
https://api.dialnexa.com/v1as the base URL. - Keep API keys in server-side environment variables or a secrets manager.
- Read the individual endpoint page before relying on its request, response, side-effect, or retry behavior.
Authenticate DialNexa API requests
An API key has a key ID and secret separated by a colon. Send the completekey_id:secret value as a Bearer token on every request.
401 Unauthorized. On this endpoint the body is:
Invalid API key in message.
Every operation under Endpoints supports Bearer API key authentication. Never send an API key from browser or mobile client code, commit it to source control, or include it in logs and screenshots.
Avoid common authentication mistakes
- Send the full
key_id:secretvalue, not only the key ID. - Use the
Authorization: Bearer ...header, notx-api-key. - Keep
/v1in the configured base URL. - Use separate keys for development, staging, and production.
- Rotate a key immediately after suspected exposure.
x-nexa-signature raw-body check.
Paginate DialNexa list responses
DialNexa list endpoints do not use one universal response envelope. Most paginated endpoints acceptpage and limit, but their record keys, metadata fields, defaults, and maximums vary. Treat each endpoint page as the source of truth.
Unfiltered resource endpoints use a success envelope containing
success, error, statusCode, message, data, and timestamp. Some resources already have their own data property, so records can be under data.data. Calls, batches, voices, languages, and LLM catalogs have endpoint-specific response filtering. Do not use one universal unwrapping rule for every endpoint.
For an endpoint with meta.totalPages, continue until the current page reaches the reported total:
limit (voices allow at most 50, LLM lists cap it at 100). For phone numbers, continue while data.meta.hasMore is true. Languages and transcribers return their complete lists and should not be paged.
Handle DialNexa API errors
Failed requests return one of two error bodies. Which one depends on the endpoint, the same way success responses do. Read the HTTP status from the response itself, not from the body. Calls, batch calls, voices, languages, and LLMs return onlymessage, plus data when the refusal has a code. A 400 message starts with Request validation failed: .
Branch on
data.code when it is present; the codes are stable, while message wording can change. On calls, batch calls, voices, languages, and LLMs, a 401 always carries the fixed message shown in Authenticate DialNexa API requests, and a 5xx carries An unexpected error occurred. Please try again later.
Common HTTP status codes
Always check
response.ok before using a response body:
Build reliable API clients
A timeout does not prove that a request failed. Repeating a write can create a duplicate resource, purchase another number, or place another call.Rate limits
Requests are limited to 150 requests per 60 seconds per API key, counted separately for each endpoint, so each operation has its own budget. Requests with a Bearer header are counted per API key (by key ID), so several of your servers sharing one key share each endpoint’s budget; requests without a Bearer header are counted per IP address. Requests that fail authentication still count. The counters are kept in memory on each DialNexa API server instance, so the limit can apply per instance: do not assume one exact shared budget, and pace your client from theX-RateLimit-* headers and 429 responses you receive.
Responses within the limit carry X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset (seconds until the window resets). When the limit is exceeded the API returns 429 Too Many Requests carrying only a Retry-After header with the number of seconds to wait; a 429 does not carry the X-RateLimit-* headers. The message is Too many requests, please try again later.
Set connection and total request timeouts that fit your application. For retry-safe requests, use capped exponential backoff with jitter and honor
Retry-After when the response includes it.
metadata. After an ambiguous timeout that returned no ID, list calls with agent_id, start_date, and end_date and compare each call’s to_number before deciding whether another call is needed. These filters do not guarantee a unique match.
Verify your API client
Before production traffic:- Confirm an authenticated list request returns
200. - Test each list parser against the endpoint’s actual response envelope.
- Verify string and array error messages are both handled.
- Confirm
4xxfailures are not retried automatically. - Simulate a transient read failure and confirm backoff is capped.
- Simulate a timed-out write and confirm the client reads or reconciles before retrying.
- Redact API keys, secrets, phone numbers, and sensitive metadata from logs.
Troubleshoot API client behavior
Related pages
- Quickstart: make and verify your first request.
- TypeScript and Python examples: copy complete integration workflows.
- Webhooks: verify signatures and process call-ended deliveries.
- AI coding agent integration: generate a repository-specific implementation plan and code changes.