Tracking each transactional SMS: the message id, masked numbers, statuses and charged

The short answer: every send through the API returns an id. Store it with the event that triggered the SMS (the order, the payment, the booking) and you will always be able to answer «was the customer told?». With that id, GET /v1/sms/messages/{id} gives the status, the parts, the credits and whether they have been taken yet (charged).

A send answer, field by field

Field	What it tells you
id	The SMS identifier. This is what you keep in your system.
status	The current status (see the next table).
to	The number, masked: 25884****567.
sender	The sender used: NETMSG or your Sender ID.
parts and encoding	How many parts it went out in, and with which alphabet.
credits and charged	How many credits it costs, and whether they have left the balance.
error	When it fails, the reason, such as delivery_failed.
scheduled_for, created_at, sent_at	The scheduled time (if any), when it was requested and when it went out.

The statuses

Status	What it means
scheduled	Scheduled for later with send_at. It can still be cancelled.
queued	In the queue, waiting its turn. See why an answer says queued.
sending	Going out right now.
sent	Handed to the mobile operator. It does not mean it has been read.
failed	It did not go out. The reason is in error.
cancelled	Cancelled before it went out.
simulated	Requested with a Sandbox key: nothing was sent, nothing was charged.

Why the number is masked

The full number is left out of answers so it does not spread through your system's logs and whoever reads them. So do not look SMS up by number: link each SMS to your customer through the id you stored when sending. The GET /v1/sms/messages list takes status, date and number filters, and also returns masked numbers.

Ask, or be told

Your system can learn how each SMS ended in two ways: ask with GET /v1/sms/messages/{id} now and then, or register a webhook and get a signed notice when each SMS is sent or fails. For a few texts, asking is enough; for many, the webhook saves requests. The trade-off is explained in delivery reports.

Simulated messages can only be seen with the key that created them, and the list leaves out the account's own notices, verification codes and simulated messages. If a message has «vanished», check which key sent it.

Want to know, every time, that the customer was told? See Transactional SMS.

See Transactional SMS

Categories

Categories