v2: Tracking IDs & cost

The v2 send is the v1 send plus two things serious integrations need: a client-supplied trackingId for reconciliation, and the send's cost in the response.

POSThttps://api.mobilesasa.com/v2/send/message

Parameters

Field	Type	Required	Description
senderID	string	Yes	An approved sender ID on your account.
phone	string	Yes	The recipient.
message	string	Yes	The text.
trackingId	string	Yes	Your reference for this send. An order ID, a UUID from your system. Echoed back in delivery reports so you can join them to your records.

curl -X POST https://api.mobilesasa.com/v2/send/message \
  -H "Authorization: Bearer $MOBILESASA_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "senderID": "MOBILESASA",
    "phone": "0712345678",
    "message": "Order #4521 confirmed. Delivery tomorrow between 9am-12pm.",
    "trackingId": "order-4521-confirm"
  }'

Response

json

{
  "status": true,
  "responseCode": "0200",
  "message": "Accepted",
  "messageId": "40b9fd8f-5577-4888-a980-e4955eb82165",
  "cost": 1
}

cost is the number of SMS parts this send was billed. A whole number, not a KES amount. A short message is 1; a message long enough to split into three parts is 3. Multiply by your account's per-part rate to get the shilling value, or read the rate from get-balance.

On /v2/send/bulk and /v2/send/bulk-personalized the field is the same, summed across the whole batch, and the id comes back as bulkId.

Why trackingId matters

Safe retries. If your call times out, you don't know whether the send happened. Retrying with the same trackingId lets you correlate both attempts in delivery reports instead of guessing.
Webhook joins. DLR callbacks include your trackingId, so matching a delivery status to your database row is one indexed lookup.
Audits. Support conversations get much shorter when both sides reference the same ID.

Registering your DLR callback URL

POSThttps://api.mobilesasa.com/v2/companies/

Set (or update) the HTTPS URL that receives delivery-report webhooks for your account. See Delivery reports for the payload you'll receive.

v1 and v2 share tokens, senders, balance and behaviour. You can mix them freely. Use v2 wherever you keep records; keep v1 for fire-and-forget notices.