{"id":646,"date":"2026-10-04T18:31:21","date_gmt":"2026-10-04T13:01:21","guid":{"rendered":"https:\/\/smppcenter.com\/journal\/?p=646"},"modified":"2026-10-04T18:31:23","modified_gmt":"2026-10-04T13:01:23","slug":"default-tps-limit-higher-throughput-tier-smpp","status":"publish","type":"post","link":"https:\/\/smppcenter.com\/journal\/default-tps-limit-higher-throughput-tier-smpp\/","title":{"rendered":"SMPPCenter’s Default 10 TPS Limit, and How the Pricing Tiers Actually Raise It"},"content":{"rendered":"\n

Every SMPPCenter account starts at 10 TPS. Here’s what that ceiling actually controls, what ESME_RTHROTTLED means when you hit it, why adding more binds doesn’t get you around it, and the only path that actually raises the number: moving to a higher pricing tier.<\/p>\n\n\n\n

\"Geometric
The default throughput cap is an account-level setting, not something extra binds can get around.<\/figcaption><\/figure>\n\n\n\n

Table of Contents<\/h2>\n\n\n\n
    \n
  1. The Short Answer<\/a><\/li>\n\n\n\n
  2. TL;DR<\/a><\/li>\n\n\n\n
  3. What the 10 TPS Default Actually Caps<\/a><\/li>\n\n\n\n
  4. What Happens at the Ceiling: ESME_RTHROTTLED<\/a><\/li>\n\n\n\n
  5. Why Adding More Binds Doesn’t Raise Your TPS<\/a><\/li>\n\n\n\n
  6. The Real Path Up: Tiers, Not a Throttle Request<\/a><\/li>\n\n\n\n
  7. Past Scale: What Enterprise Actually Means<\/a><\/li>\n\n\n\n
  8. Two Different “TPS” Numbers You’ll See, and Why They’re Not the Same Claim<\/a><\/li>\n\n\n\n
  9. What to Check Before You Ask for a Higher Tier<\/a><\/li>\n\n\n\n
  10. Next Steps<\/a><\/li>\n\n\n\n
  11. FAQs<\/a><\/li>\n<\/ol>\n\n\n\n

    The Short Answer<\/h2>\n\n\n\n

    Every SMPPCenter<\/strong> account starts at a default throughput of 10 TPS (10 messages per second), regardless of which SMPP bind setup you use. Go over it and submissions get rejected with error code 0x00000058, ESME_RTHROTTLED. That cap sits at the account level, so opening a second or third bind session doesn’t raise it. The number actually moves when you change pricing tier: Launch tops out at 50 TPS, Growth at 200, Scale at 500, and Enterprise is quoted individually above that. There’s no separate “throughput request” form or self-service dial between tiers; the tier is the dial.<\/p>\n\n\n\n

    \n\n\n\n

    TL;DR<\/h2>\n\n\n\n

    If you’re sending at a steady pace under 10 messages a second, this won’t come up. If you’re running a campaign blast, syncing a large contact list, or an aggregator pushing traffic from multiple downstream resellers through one account, you’ll hit the ceiling faster than you’d expect, and the fix isn’t a code change on your end. Build in throttle control and retry logic for 0x00000058 regardless of which tier you’re on (it’s good practice even at 500+ TPS), and if your actual sustained volume needs more than your current tier allows, the conversation to have is about upgrading the plan, not about tuning your SMPP client<\/a><\/strong> harder.<\/p>\n\n\n\n

    \n\n\n\n

    What the 10 TPS Default Actually Caps<\/h2>\n\n\n\n

    The number is per account, not per connection. SMPPCenter’s own documentation on controlling throttling over SMPP connectivity<\/a> states it plainly: “By default, SMPPCenter’s SMPP Client’s account is assigned with a throughput of 10 TPS (10 SMS per second).” That’s the baseline every new SMPP client starts on before any plan-level throughput is applied.<\/p>\n\n\n\n

    Ten messages a second sounds small until you do the math on what it actually covers. At a sustained 10 TPS you can push 36,000 messages an hour, which is plenty for OTP traffic on a small to mid-size app, or a steady drip of transactional alerts. It falls over fast the moment you’re doing anything bursty: a promotional blast to a segment of 50,000 numbers fired in one go, a backup job that re-sends a day’s worth of failed deliveries all at once, or several resellers under one master account all submitting at the same time without any coordination between them.<\/p>\n\n\n\n

    This is also where the plan tiers come in, because the 10 TPS figure isn’t really “the” SMPPCenter limit, it’s the floor. The pricing page<\/a> sets a different ceiling per plan, and that plan-level number is what replaces the 10 TPS default once you’re on a paid tier. More on the actual figures in a minute.<\/p>\n\n\n\n

    \n\n\n\n

    What Happens at the Ceiling: ESME_RTHROTTLED<\/h2>\n\n\n\n

    This part isn’t SMPPCenter-specific at all. It’s straight out of the open SMPP protocol specification maintained at smpp.org<\/a>, and it behaves the same way across any SMPP server, not just SMPPCenter’s. When you submit faster than the connection’s allowed rate, the server responds to your submit_sm<\/code> with a command_status<\/code> of 0x00000058, which is the status code ESME_RTHROTTLED. Your message wasn’t queued or deferred, it was rejected outright, and it’s on your client code to resubmit it.<\/p>\n\n\n\n

    SMPPCenter’s KB page gives the same two-part recommendation you’d get from any competent SMPP vendor: coordinate your submission rate with your approved throughput so you’re not hitting the wall in the first place, and resubmit any submit_sm<\/code> that comes back with 0x00000058 rather than treating it as a hard failure and dropping the message. That second part matters more than it sounds. A naive integration that logs the error and moves on will silently lose messages during any burst, which is a worse outcome than a slower, throttled send.<\/p>\n\n\n\n

    If you’re coming from a platform that implements the newer SMPP v5.0 congestion_state TLV, don’t expect SMPPCenter to signal congestion that way unless it’s documented somewhere you can point to; the public KB content only describes the rejection-and-resubmit pattern from the older, more widely deployed throttling model. Build your retry logic around the status code you can actually confirm, not around a congestion-state field you’re assuming is there.<\/p>\n\n\n\n

    A practical retry loop looks roughly like this, written generically rather than as a documented SMPPCenter API contract:<\/p>\n\n\n\n

    on submit_sm response:\n  if command_status == 0x00000058 (ESME_RTHROTTLED):\n    wait (backoff interval)\n    resubmit same submit_sm\n  else if command_status == 0x00000000 (success):\n    mark message as submitted, continue\n  else:\n    handle according to that specific error code\n<\/code><\/pre>\n\n\n\n
    The backoff interval isn’t published anywhere, so don’t hardcode a number you read off a vendor’s blog as if it’s SMPPCenter’s own tuning. Start conservative (a few hundred milliseconds), watch your rejection rate, and adjust.<\/p>\n\n\n\n
    \n\n\n\n
    Why Adding More Binds Doesn’t Raise Your TPS<\/h2>\n\n\n\n
    This is the misconception that costs people the most debugging time. SMPPCenter<\/strong> supports binding as two transceiver sessions, or as a separate transmitter and receiver pair, documented on the bind types KB page<\/a>. That page frames the choice between those bind patterns as a deployment and architecture decision, not a performance one, and it doesn’t attach a window size or PDU-depth figure to either option.<\/p>\n\n\n\n
    The throughput figure is tied to the account, not to how many sessions you have open against it. Opening three transceiver binds instead of one doesn’t give you three times the TPS<\/a>; it gives you three ways to submit against the same shared 10 TPS (or plan-level) ceiling. If anything, splitting traffic across multiple binds without coordinating the combined rate makes it easier to blow past the limit by accident, because each bind’s client code might be tracking its own local rate without knowing what the other binds are sending at the same moment.<\/p>\n\n\n\n
    Where multiple binds genuinely help is resilience and traffic separation, covered in SMPPCenter’s own fail-over<\/a> and routing feature set: if one session drops, a healthy second session keeps traffic moving, and separating a transmitter from a receiver can simplify how your application handles inbound delivery receipts versus outbound submissions. None of that changes the account’s assigned TPS number.<\/p>\n\n\n\n
    If your current integration is already using multiple reseller sub-accounts or connectors against the same master account (a CRM connector and an e-commerce plugin running at the same time, for instance), the same rule applies at that level too: they’re drawing from one shared throughput budget, not one each.<\/p>\n\n\n\n
    \n\n\n\n
    The Real Path Up: Tiers, Not a Throttle Request<\/h2>\n\n\n\n
    There’s no published form, API call, or support ticket category on smppcenter.com for “raise my TPS without changing anything else.” The number is baked into the plan you’re on. From the pricing page<\/a>:<\/p>\n\n\n\n
    Plan<\/th>TPS Ceiling<\/th>Monthly Volume<\/th><\/tr><\/thead>
    Launch Web<\/td>up to 50 TPS<\/td>1M messages\/month<\/td><\/tr>
    Launch SMPP<\/td>up to 50 TPS<\/td>1M messages\/month<\/td><\/tr>
    Growth<\/td>up to 200 TPS<\/td>5M messages\/month<\/td><\/tr>
    Scale<\/td>up to 500 TPS<\/td>15M messages\/month<\/td><\/tr>
    Enterprise<\/td>1,000+ TPS, negotiated<\/td>negotiated<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    So the practical answer to “how do I get more throughput” is “which plan are you paying for right now.” If you’re on Launch and hitting 50 TPS regularly, the fix is moving to Growth, not finding a hidden throttle-control setting on Launch. Same logic applies moving from Growth to Scale.<\/p>\n\n\n\n
    It’s worth being honest about something the public pricing page doesn’t spell out: whether moving tiers is instant or involves any manual provisioning step on SMPPCenter’s side. That detail isn’t published, so don’t assume either way, and budget a conversation with their team rather than expecting an account-panel toggle to flip the moment you upgrade billing.<\/p>\n\n\n\n
    One more thing worth flagging if you’re evaluating a perpetual license instead of a subscription: the TPS ceiling is tied to the tier (Growth or Scale, the only two tiers perpetual licensing is offered on), not to the billing model. A perpetual Growth license still caps at 200 TPS; switching from subscription to perpetual on the same tier doesn’t change your throughput, only who’s responsible for hosting and maintaining the infrastructure.<\/p>\n\n\n\n
    \n\n\n\n
    Past Scale: What Enterprise Actually Means<\/h2>\n\n\n\n
    Scale’s published ceiling is 500 TPS. Above that, the pricing page moves to “Enterprise: custom,” with 1,000+ TPS and unlimited reseller accounts as the headline figures, and pricing negotiated rather than listed. That’s a meaningfully different sales motion than picking Launch, Growth, or Scale off a price list: there’s no fixed number to plan against until you’re actually in that conversation, and the public site doesn’t state how TPS scales within Enterprise past the 1,000 floor, whether it’s a flat negotiated ceiling, a scaling fee per additional TPS block, or something else.<\/p>\n\n\n\n
    If your actual traffic need is in the low hundreds of TPS, Scale is a known, published quantity. If you’re anticipating sustained traffic meaningfully above 1,000 TPS, that’s a conversation to start early rather than something to assume will “just work” once you sign an Enterprise contract, since none of the mechanics of how Enterprise throughput is provisioned are public.<\/p>\n\n\n\n
    It’s also worth separating two different kinds of “we need more TPS” conversations before you get on a call. One is a capacity conversation: your steady-state traffic has genuinely grown past 500 TPS and you need a contract that reflects that on an ongoing basis. The other is a burst conversation: your steady-state traffic is well within Scale, but once or twice a year you run a campaign that needs a short-lived spike well above your normal rate. Those are different problems, and nothing on the public pricing page suggests Enterprise contracts are priced or structured for occasional bursts versus sustained baseline volume. If what you actually need is short-term headroom around a product launch or a seasonal push, say that explicitly rather than describing it as a permanent throughput increase, since the two are likely to be quoted differently.<\/p>\n\n\n\n
    \n\n\n\n
    Two Different “TPS” Numbers You’ll See, and Why They’re Not the Same Claim<\/h2>\n\n\n\n
    Here’s something that trips people up when they’re cross-referencing pages on the site: SMPPCenter’s features page<\/a> states a platform figure of up to 2,000 TPS, while the homepage separately states up to 10,000 TPS, and neither of those is the same thing as the per-tier ceilings on the pricing page (which top out at 500 TPS before you reach Enterprise).<\/p>\n\n\n\n
    These aren’t contradictory so much as they’re answering different questions. The pricing-tier numbers (50\/200\/500\/1,000+) are what’s assigned to your specific account on your specific plan. The features-page and homepage figures read as platform-capability claims, what the underlying software architecture can handle under the right conditions, not a number any single account is automatically provisioned at. Think of it the way you’d think of a database vendor advertising “built for a million writes per second” in their architecture docs while your actual plan’s connection pool caps you at a few thousand: both statements can be true at once because they’re describing different layers.<\/p>\n\n\n\n
    The high-throughput scaling piece<\/a> in the journal leans into the architecture side of this, covering techniques for handling 2,000+ TPS at the platform level. That’s a useful read if you’re trying to understand how the system scales in principle. It’s a different question from what’s actually sitting on your account today, which is governed by your tier.<\/p>\n\n\n\n
    If you’re citing a TPS figure anywhere in a proposal, SLA discussion, or internal capacity plan, use the pricing-page number for your tier, not the architecture-capability number, unless SMPPCenter has confirmed in writing that your specific account or contract carries the higher figure.<\/p>\n\n\n\n
    This distinction matters most when you’re the one reselling access downline. If you’re a reseller quoting your own sub-accounts a throughput figure, quoting the homepage’s 10,000 TPS or the features page’s 2,000 TPS as “what you’ll get” sets an expectation your master account can’t deliver unless you’re specifically on a tier or contract that supports it. Quote what your plan actually states, and treat the bigger numbers as background on platform architecture, not as a number to pass down the chain.<\/p>\n\n\n\n
    \n\n\n\n
    What to Check Before You Ask for a Higher Tier<\/h2>\n\n\n\n
    Before assuming you need a plan change, it’s worth ruling out a few things that look like a throughput ceiling but aren’t:<\/p>\n\n\n\n