Skip to main content
REST, unless you have a reason not to. One HTTPS call per message, nothing to keep alive, and every language speaks it.SMPP earns its complexity at high sustained volume, where a persistent bind avoids a TCP and TLS handshake per message, and where you want the protocol carriers themselves use.Everything downstream of acceptance is identical either way — same routing, rating, approvals and receipts.
No. Credentials are typed HTTP or SMPP, and the two are not interchangeable. Ask for one of each if you need both.This is the cause of a 403 Authentication failure that survives every password check: the login is fine, it is simply the wrong type for the door you are knocking on.
That is your provider’s decision, not a property of the gateway. Ask them.What exists everywhere is /secure/rate, which prices a message without sending it, charging nothing and counting against no rate limit — enough to validate destinations, encoding and pricing before you send anything real.
No. The API is small enough that an HTTP client and four lines of code cover it — see Quickstart for curl, Node, Python and PHP.
Check any OpenAPI document you were given against these pages before generating a client. An older specification is still in circulation that types custom_tlvs as an array when it must be an object, types validity_period as a string when it must be an integer, and omits product.
Your provider’s, not a fixed one — each operator runs their own FireFlo. Every example here uses https://sms.example.com as a stand-in.
Yes, if you send in bursts. Your account has a messages-per-second limit; over it you get 429 with no Retry-After header.Back off exponentially with jitter. A fixed retry interval across several workers re-synchronises them into the next burst, turning a momentary limit into a sustained one.
A delivery receipt, and only that. Ask for one with "dlr": "yes" and a dlr_url.Wait for a level 2 receipt. ACCEPTD and BUFFRED arrive as level 1 and another follows — a client treating the first receipt as final reports the wrong outcome permanently.
Because you sent three submit_sm. conf.dlr.multipart defaults to all, so there is one receipt per segment you submitted, each quoting the id you were given.Your provider can set it to first or last to collapse that to one. Every receipt reports the same outcome whichever they choose, because the segments are aggregated before any receipt is built.
Because the recipient did not receive a readable message. Resolution waits for the last segment and reports the worst outcome, not the first.It is the honest answer, and it moves delivery-rate figures down relative to gateways that report the first segment — worth knowing before comparing providers on a delivery-rate number.
Yes — the customer portal shows your own messages with search and a CSV export, and your statement separately. See the portal.You see the TLVs you sent on your own messages. What a vendor added downstream is not yours to see.