Reselling Through an API: What to Build and What to Expect

2026-08-29 · 7 min read

Almost every SMM panel exposes the same handful of endpoints, because they all descend from the same original implementation. Learning them takes an afternoon. Building something that does not lose orders takes considerably longer, and the difficulty is never in the request format.

The endpoints you get

• Services: the catalogue, with rates, minimums, maximums and flags
• Add: place an order, returns an order id
• Status: one order or several, returns a state and a remains count
• Refill: request a top-up where the service supports it
• Balance: what you have left to spend

That is the whole surface. Everything you build sits on top of those five, and the interesting problems all live in how you handle their failure modes.

Idempotency is the first real problem

The add endpoint has no idempotency key in the standard design. If your request times out, you do not know whether the order was placed. Retrying may double-charge; not retrying may lose the order. Neither is acceptable.

The fix is on your side: record your intent to order before you call, store your own reference against it, and on an ambiguous failure reconcile against the supplier's order list rather than blindly retrying. This is the single most common cause of duplicate orders in reseller systems and it is entirely preventable.

Order state is not linear

Orders go pending, then in progress, then completed. They also go partial, canceled, and occasionally back from completed to in progress when a refill runs. Code that assumes a one-way progression breaks the first time a supplier reopens an order, and it breaks silently, which is worse.

Model the state as whatever the supplier last said, plus your own derived view of what the customer is owed. Keeping those two separate is what lets you handle a partial correctly without rewriting history.

Polling, and how not to get rate limited

Status supports batches. Use them. Polling every order individually every minute is how accounts get throttled, and throttling arrives exactly when you have the most orders in flight. Poll aggressively for the first hour of an order's life, then back off — most orders that are going to complete do so early, and the rest are not going to be helped by asking more often.

The catalogue drifts under you

Suppliers rename categories, change rates, retire services, and reuse identifiers. A cached catalogue that is a week old will happily place an order against a service that no longer means what it meant. Re-sync regularly, key your own services on the supplier identifier rather than the name, and treat a rate change as an event that needs a decision rather than a value to overwrite.

What this buys you

Done properly, an API integration means your own smm panel carries thousands of services without anyone touching a spreadsheet, prices update themselves, and orders reconcile without a human. Done carelessly it means a support queue full of orders that were charged twice or never placed. The difference is entirely in the handling of the ambiguous cases, and those are the cases the documentation does not cover.