The number behind the hash.
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.
- Directions
- BothDirections
- Networks detected
- 4Networks detected
- Or in the portal
- APIOr in the portal
The delivery report says
9532b0ef1e65c7dadf2d133e05cfe9b00fb8e9ad5806182bcb5255c2e7e9648bf
Phone lookup
Your customer
0712 345 678
Delivered09:41:22· SafaricomReports you can actually act on
A delivery report you cannot tie to a customer is a delivery report you cannot use. This closes that gap in both directions.
- Both directions
- Number to hash, or hash back to number. You send whichever you have; we work out which way round it is.
- Network detection
- Every lookup names the network from the number's prefix (Safaricom, Airtel, Telkom or Equitel), so you can price or segment a list before you send. A number that has moved networks keeps its old prefix.
- Match at scale
- 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.
- In the portal too
- A tool in the sidebar for support and one-off checks, so nobody needs a developer to answer “who is this hash”.
- Honest about misses
- A hash we have never seen returns a plain answer saying so, not an error. A miss means we have never messaged that subscriber.
- Any format in
- 07…, 2547…, +2547… all work. Output is always clean E.164, so what you store stays consistent.
The problem it solves
Your report says a hash. Your CRM says 0712 345 678.
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.
- Decode hashed delivery reports back to real numbers
- Reconcile shortcode and USSD events to customer records
- Answer support questions without guessing
- Works for one number or a whole export
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
Know the network before the message leaves
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.
- Safaricom, Airtel, Telkom and Equitel
- Catches malformed numbers at import, not at send
- Feeds per-network reporting and cost analysis
- Same answer the sending platform uses
Network detection
- 0712 345 678Safaricom
- 0733 987 654Airtel
- 0770 111 222Telkom
- 0763 444 555Equitel
Live in four steps
- 01
Paste what you have
A phone number in any Kenyan format, or a 64-character hash from a report. The tool works out which it is.
- 02
Get the other form
The number, its network and its hash, so you can match the two by eye or store both.
- 03
Do it in bulk
Call the API from your import job, store the hash beside each contact, and match every future report locally.
What teams use it for
Shortcode and USSD operators · Teams reconciling delivery exports · Support desks answering “did it arrive” · CRMs matching campaign results · Compliance and audit reviews · Anyone handed a hashed MSISDN
Questions people ask
Why are some phone numbers hashed at all?
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.
Can every hash be turned back into a number?
No, and no service can promise otherwise, because 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.
Do I need to call the API for every delivery report?
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.
Is it available without writing code?
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.
What does it cost?
KES 0.10 for each hashed phone we match to a number, charged from your wallet at the moment of the answer. Turning a number into its hash, reading its network, and a hash we cannot match cost nothing. It uses the same permission that reads your message history.
Works well with
The campaigns and delivery reports this decodes for you.
Inbound events where hashed numbers show up most often.
Match survey responses back to the people who sent them.
Stop guessing who a hash belongs to
Open the lookup tool in your portal, or wire the API into your reconciliation job. KES 0.10 per resolved number, charged from your wallet. A hash we cannot match costs nothing.