Send a message

POST

/api/v1/sms/messages

API key or session

Sends one SMS using one of your approved templates.

Request

Field	Type	Description
`to`required	string	Indian mobile number. 10 digits, or 12 with the 91 country code. Spaces, hyphens, brackets and a leading + or 0 are ignored, so a value pasted from a spreadsheet works.
`dlt_template_id`required	string	The 19-digit content template ID, as approved. The template must be approved on your account, and its sender ID approved, or the request is refused.
`variables`	string[]	Values for the template's {#var#} placeholders, in order. The count must match the template exactly. Each value is capped at 30 characters. Omit for a template with no variables.

curl -X POST https://api.splashifypro.com/api/v1/sms/messages \
  -H "Authorization: Bearer sms_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "9876543210",
    "dlt_template_id": "1234567890123456789",
    "variables": ["482913", "10"]
  }'

Response

{
  "success": true,
  "accepted": true,
  "message_id": "0f1c2d3e-4a5b-6c7d-8e9f-0a1b2c3d4e5f",
  "status": "sent",
  "parts": 1,
  "unicode": false,
  "charged": 0.18,
  "balance_after": 1250.32
}

Field	Type	Description
`accepted`	boolean	Whether the network took the message. Check this, not just the HTTP status: a refused message still returns 200.
`message_id`	string	Ours. Store it; it is how you read the message later and the one thing support needs.
`status`	string	sent, rejected or pending. Not yet a delivery outcome.
`parts`	number	What you were charged for. See the manual on message parts.
`unicode`	boolean	True when the message needed the Unicode alphabet, which fits 70 characters per part instead of 160. A rupee sign is the usual cause.
`charged`	number	Rupees debited. Zero when nothing was charged.

A rejected message returns 200

This surprises people, so it is worth stating plainly.

If the request was well-formed and we processed it, the status is 200 even when the network refused the message. accepted is false and message explains it.

Why not 4xx

A 4xx would tell your code it sent a bad request, when what actually happened may be a configuration problem on our side that your retry logic cannot fix. Retrying a well-formed request against a problem that is not yours just produces load. Branch on accepted.

{
  "success": false,
  "accepted": false,
  "message_id": "0f1c2d3e-...",
  "status": "rejected",
  "message": "That mobile number does not look valid. Check it and try again.",
  "charged": 0
}

A message that is not accepted is never charged, and the text says so where the cause was not yours.

When the request itself fails

Field	Type	Description
`400`	bad request	Missing or malformed field, or the wrong number of variables.
`401`	auth	Invalid API key.
`402`	balance	Wallet too low. Nothing was sent or charged.
`404`	template	No such template on your account.
`429`	rate limit	Slow down and retry shortly.
`503`	unavailable	Sending is not available right now. Retry.

Other refusals arrive as 400 with a specific message: a template not yet approved, a sender ID not yet approved, or a DLT chain not yet verified. Each names what to fix, and none of them is retryable until you fix it.

Sending to a list

There is no bulk endpoint yet. Send one request per recipient, and:

Keep to the rate limit. A 429 means slow down, not fail.
Store every message_id. Reconciling a campaign without them is guesswork.
Check your balance first with GET /balance, rather than finding out halfway through.

Accepted is not delivered

The response tells you the network took the message. Whether it reached a handset comes later, through Message status or a delivery webhook.

Send a message

Request#

Response#

A rejected message returns 200#

When the request itself fails#

Sending to a list#