Skip to main content
DialNexa API fundamentals cover the four behaviors every production client needs: Bearer API key authentication, endpoint-specific pagination, structured error handling, and safe retry decisions. Use this page after the Quickstart and before sending real customer traffic.

Before you build a DialNexa API client

  • Create an API key in Settings > API Keys.
  • Use https://api.dialnexa.com/v1 as 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 complete key_id:secret value as a Bearer token on every request.
A missing, revoked, expired, or malformed key returns 401 Unauthorized. On this endpoint the body is:
Endpoints outside calls, batch calls, voices, languages, and LLMs return the full error envelope described in Handle DialNexa API errors, with a reason such as 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:secret value, not only the key ID.
  • Use the Authorization: Bearer ... header, not x-api-key.
  • Keep /v1 in the configured base URL.
  • Use separate keys for development, staging, and production.
  • Rotate a key immediately after suspected exposure.
Webhook deliveries use a separate HMAC signature. For subscriptions created with the API, see Verifying the signature for the x-nexa-signature raw-body check.

Paginate DialNexa list responses

DialNexa list endpoints do not use one universal response envelope. Most paginated endpoints accept page 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:
For calls, batch calls, voices, and LLM lists, stop when a page contains fewer records than the effective 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 only message, plus data when the refusal has a code. A 400 message starts with Request validation failed: .
Every other endpoint returns the full error envelope:
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.
The current v1 contract does not define an idempotency header. Do not invent one.

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 the X-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.
For calls, keep a local correlation record and save the returned DialNexa call ID, then reconcile with that ID. API-key call responses do not return arbitrary 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:
  1. Confirm an authenticated list request returns 200.
  2. Test each list parser against the endpoint’s actual response envelope.
  3. Verify string and array error messages are both handled.
  4. Confirm 4xx failures are not retried automatically.
  5. Simulate a transient read failure and confirm backoff is capped.
  6. Simulate a timed-out write and confirm the client reads or reconciles before retrying.
  7. Redact API keys, secrets, phone numbers, and sensitive metadata from logs.

Troubleshoot API client behavior