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 for delivery",
  "cost": 0.8
}

cost is the KES value of this send at your account rate, including multi-part splitting — reconcile spend in real time without polling the balance endpoint.

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.