Signal & Syntax · Guide
Number Validation Over SMPP
If your platform already runs an SMPP bind, validation can run on the same bind. Each lookup goes out as one submit_sm. The result comes back in the delivery receipt.
6 minUpdated ScoreMachine team
What SMPP Is
SMPP (Short Message Peer-to-Peer) is the protocol SMS platforms use to exchange traffic with an SMSC. A client opens a TCP connection and binds with a system ID and a password. The bind stays open between messages.
Messages go out as submit_sm. Receipts come back as deliver_sm. SMS gateways, SMS aggregators and CPaaS platforms send most A2P SMS this way. How A2P SMS reaches a handset shows where SMPP sits on the path.
Why Validate on a Bind
A platform that speaks SMPP already runs the client, the queue and the receipt handler. Validation over SMPP reuses all three. There is no HTTP client to add and no second sign-in to manage.
JSON-RPC and SMPP reach the same methods on the same account. The check runs inside the send path, before a message leaves the queue. Drop a failed number there, and it never reaches the SMSC.
How a Lookup Travels
Session
→ bind_transceiver system_id, password ← bind_transceiver_resp command_status 0x00000000 → submit_sm destination_addr 447911123456, registered_delivery 1 ← submit_sm_resp message_id 7f3a9c21 ← deliver_sm esm_class 0x04, the receipt with the result → deliver_sm_resp acknowledge the receipt ↔ enquire_link every 30 seconds while idle
Your client binds once and keeps the session open. Each lookup is one submit_sm with the number in destination_addr. Send the number in E.164 digits without the plus sign, with TON 1 and NPI 1. Set registered_delivery to 1, or no receipt comes back.
The router answers with submit_sm_resp and a message_id. The result arrives later as a deliver_sm carrying a delivery receipt. An esm_class of 0x04 marks it as a receipt. Acknowledge each one with deliver_sm_resp.
No SMS reaches the handset. The router answers the lookup itself and sends nothing to the number. It terminates lookup traffic and never forwards it to a network.
Reading the Receipt
Receipt
id:7f3a9c21 sub:001 dlvrd:001 submit date:2609261412 done date:2609261412 stat:DELIVRD text:VALID
The receipt follows the common SMPP 3.4 layout. id matches the message_id from submit_sm_resp. stat is always DELIVRD, and text carries the eHLR result.
The receipt describes +44 7911 123456, ported from O2 to Vodafone UK. eHLR is ScoreMachine's own activity check. HLR lookup vs eHLR explains the check behind text. Mobile number portability explains why routing follows the serving network.
A DELIVRD here reports a lookup, not a delivered message. Keep lookup receipts apart from send receipts in your handler. A separate system_id for lookups keeps the two streams apart at the bind.
Connection Settings
SMPP 3.4 caps the password at eight characters.
The router returns one of two values in command_status of submit_sm_resp. ESME_RTHROTTLED (0x58) means the incoming CPS is exceeded: slow down, then retry. ESME_ROK (0x00) covers every other case.
SMPP or JSON-RPC
Pick SMPP when numbers already flow through a bind. Pick JSON-RPC for uploaded lists and for features inside your own product. Both run on the same account. Developers covers the JSON-RPC methods.
Getting a Bind
SMPP access is set up with our team. Credentials are issued on request only. Bring your expected volume and the SMPP client you run.
Try each check free on one number: Phone Number Checker, Carrier Lookup and Ported Number Checker.
Terms in this guide