Resources · API

API reference

REST over HTTPS, JSON in and out. Every example below is a working request — copy it, add your key, and it runs.

Authentication

Every request carries a bearer token. Create keys in the portal under Developer API. Keys are shown once at creation and stored hashed — we cannot recover one for you, so keep your own copy.

Authorization: Bearer nxt_live_xxxxxxxxxxxxxxxxxxxx

Base URL: https://nexistxt.com/api/v1

POST/api/v1/send

Send a message

One recipient per call. The whole request is validated — key, IP, rate, DLT header, template, variable count — before anything is queued or billed, so a rejected request has sent nothing and charged nothing.

curl https://nexistxt.com/api/v1/send \
  -H "Authorization: Bearer $NEXISTXT_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "header": "METNDE",
    "template_id": "1777178539978637333",
    "to": "919820012345",
    "vars": ["GANGA", "1.96"]
  }'

header — a sender ID registered to your entity and approved. template_id — your approved DLT template; its category must match the header’s. to — E.164 or a bare 10-digit Indian number. vars — one value per {#var#} slot, in order.

{
  "message_id": "msg_m2p9x4a1b2c3",
  "status": "submitted",
  "segments": 1,
  "encoding": "GSM-7",
  "cost": 0.14
}

200 with status: "submitted" means an operator has accepted it and your wallet has been debited. A deterministic failure — unregistered header, template mismatch, wrong variable count, invalid number — returns 422 with an error_code and is not billed. An empty wallet returns 402.

GET/api/v1/messages/{message_id}

Fetch a message

Current state of one message, including the operator’s own error code if it failed.

curl https://nexistxt.com/api/v1/messages/msg_m2p9x4a1b2c3 \
  -H "Authorization: Bearer $NEXISTXT_KEY"

{
  "message_id": "msg_m2p9x4a1b2c3",
  "to": "919820012345",
  "header": "METNDE",
  "category": "P",
  "status": "delivered",
  "submitted_at": "2026-08-09T10:31:02+05:30",
  "delivered_at": "2026-08-09T10:31:07+05:30",
  "segments": 1,
  "cost": 0.14,
  "error_code": null
}

Statuses: queued · submitted · delivered · failed · expired. The last three are final. error_code is a stable value from our own vocabulary rather than the carrier’s string, so it does not change when we change carrier.

POSTyour webhook

Delivery receipts

We post each receipt to your configured URL. Receipts can arrive minutes or hours after submission — operator retry windows run for up to 72 hours — so treat the webhook as eventual, not immediate.

POST https://your-app.example/dlr
X-Signature: t=1785000000,v1=5a3f...

{
  "message_id": "m_01J8Z...",
  "client_message_id": "order-4417",
  "to": "919820012345",
  "status": "delivered",
  "error_code": null,
  "delivered_at": "2026-08-09T10:31:07+05:30"
}

The signature is HMAC-SHA256 over {timestamp}.{body} with your webhook secret. Verify it against the raw body — re-serialising the JSON changes bytes and the signature will not match. Respond 2xx; we retry a non-2xx at 1m, 5m, 15m and 1h.

GET/api/v1/balance

Wallet balance

Check before a large send. The account is prepaid and a campaign will hold rather than partly send.

curl https://nexistxt.com/api/v1/balance \
  -H "Authorization: Bearer $NEXISTXT_KEY"

{
  "balance": 12480.50,
  "currency": "INR",
  "low_balance_threshold": 500.00,
  "low_balance": false
}

Errors

Errors return a JSON body with error and, where we can be specific, the field at fault.

400Malformed request — a required field is missing or the wrong type.
401The API key is missing, wrong, or has been revoked.
402Insufficient wallet balance. The account is prepaid; add credit and retry.
403The sender ID or template is not registered to your entity.
422The request is well formed but cannot be accepted — a template mismatch, a category conflict, or a variable over its approved length.
429You exceeded your account TPS. Back off and retry; the limit is account-wide, not per connection.
503We could not accept the message durably. Retry — this is safe, nothing was queued.

Rate limits

Your TPS ceiling is account-wide, not per connection or per API key. Opening more connections buys redundancy and latency smoothing, never throughput — this is the single most common misunderstanding, so it is worth stating plainly. Exceeding it returns 429 with Retry-After.

Something missing or wrong here? Tell us — the reference should answer the question without an email.