Mobile Sasa has a new home. Same sender IDs, same paybill, same APIs. Nothing to rebuild.
Open the new portal →Safaricom hands out scrambled phone numbers in some reports. Phone lookup turns them back into the numbers your records use — and turns your numbers into hashes so you can match the two at scale.
What's included
A delivery report you cannot tie to a customer is a delivery report you cannot use. This closes that gap in both directions.
Number to hash, or hash back to number. You send whichever you have; we work out which way round it is.
Every lookup names the carrier — Safaricom, Airtel, Telkom or Equitel — so you can route, price or segment before you send.
Hashing is deterministic: compute it once when a contact is imported, store it beside the number, and match hashed reports without a single API call.
A tool in the sidebar for support and one-off checks, so nobody needs a developer to answer “who is this hash”.
A hash we have never seen returns a plain answer saying so, not an error — a miss means we have never messaged that subscriber.
07…, 2547…, +2547… all work. Output is always clean E.164, so what you store stays consistent.
The problem it solves
On some Safaricom traffic the subscriber number arrives scrambled — in delivery reports, in shortcode events, in the message file you download. Without a way between the two forms, “did this customer get their message” has no answer.
Your report, after lookup
| Customer | Number | Status |
|---|---|---|
| Jane Wanjiku | 0712 345 678 | Delivered |
| Peter Otieno | 0733 987 654 | Delivered |
| Grace Muthoni | 0722 111 222 | Phone off |
Before you send
Every lookup names the carrier the number belongs to. Useful for routing decisions, for pricing by network, and for catching a mistyped number before it becomes a failed send you paid for.
Network detection
How it works
A phone number in any Kenyan format, or a 64-character hash from a report. The tool works out which it is.
The number, its network, and its hash — so you can match the two by eye or store both.
Call the API from your import job, store the hash beside each contact, and match every future report locally.
Use cases
FAQ
Safaricom scrambles the subscriber number in certain report and event feeds. It is their privacy measure, and it applies to the data we pass on to you unchanged. The hash is stable, so the same number always produces the same hash.
No, and no service can promise otherwise — hashing is one-way arithmetic. What we can do is match a hash against numbers the platform has already handled. If we have never messaged that subscriber, the lookup says so plainly rather than guessing.
No, and you should not. Number-to-hash is deterministic: compute the hash once when a contact enters your database and store it alongside the number. Then matching hashed reports is a local join with no API calls at all.
Yes. It is a tool in the portal sidebar — paste a number or a hash and get the answer. The API is there for the volume case.
Nothing extra. It is part of your account, scoped to the same permission that reads your message history.
Open the lookup tool in your portal, or wire the API into your reconciliation job — both are included with your account.