SMM API in Brazil: How the Market Standard Integration Works

Anyone who has integrated more than one engagement supplier notices it fast: nearly every SMM panel speaks the same API dialect. This guide explains that standard format, the four actions that cover an entire integration, the difference between prepaid and postpaid balance, and the detail that separates a reliable integration from one that risks charging the same order twice: idempotency. As a concrete reference, the SegBoost catalog exposes 5 services through this dialect, with wholesale pricing starting at R$ 0,20 per thousand on views, and each minimum order comes in the `services` response itself.

The format that became the SMM panel standard in Brazil

The convergence is significant: a single POST call to one address, with two required fields in the body, an access key and the action you want to run. This format was born at one supplier and spread because it cuts the work for whoever is integrating. The same code that talks to one supplier just swaps address and key to talk to another, without rewriting the entire order logic.

A more modern alternative exists, following the REST pattern with JSON and token authentication in the header, but it is the exception. The action based format remains the market standard, and it is what every reseller panel expects to find on the other end.

The four actions every integration uses

Minimum coverage for any integration fits into four actions.

• services: returns the entire catalog, with price per thousand, minimum and maximum quantity and whether the service has a refill.
• balance: returns the available account balance, essential because the model is prepaid and no order ships without credit.
• add: creates a new order, providing the service, the destination link or username and the quantity.
• status: checks the progress of one or several orders at once, including how much has been delivered and how much is left.

Prepaid or postpaid: why it changes the risk for whoever integrates

Most of the SMM panel market runs on prepaid balance: you load credit ahead of time, and each order debits it the moment it is confirmed. There is no end of month invoice and no credit check, which is why anyone can open an account and start reselling the same day.

The postpaid model, with an invoice closed later and billing by period, is rare in this market and usually reserved for large accounts with a track record. For anyone integrating, the practical difference is where the error shows up: with prepaid, insufficient balance blocks the order right away, with a clear error. A well built integration handles that error on purpose, instead of letting the end customer see a generic failure screen.

Idempotency: why repeating an order cannot charge it twice

Every integration will eventually face a call that stalls midway: the connection drops, the timeout hits, and whoever called the API does not know whether the order was created on the supplier's side or not. The naive response is to retry, and that is exactly where the risk of duplicating the charge and creating two identical orders for the same customer comes from.

Idempotency is the guarantee that repeating the same call, within a short time window, does not create a second order or debit the balance twice. In the action based format, this protection usually recognizes the repeated order by the same parameters sent in sequence and returns the order that already exists instead of creating another. In the REST format, the same guarantee is explicit: the caller sends its own idempotency identifier, and resending it with the same identifier returns the result of the original order.

Errors every integration needs to handle

An integration that only handles the happy path breaks at the first spike in usage. The most common errors already come with a standardized message, and it is worth mapping each one before going to production.

• Insufficient balance: the order is not created, and the message clearly states the account is short on credit.
• Incorrect service: the service identifier sent does not exist in the supplier's current catalog.
• Incorrect link: the link or username format sent does not match what the service expects.
• Incorrect key: the access key is wrong, expired, or has been revoked.

Before writing the first line of the integration

The wholesale price table and the rest of the technical detail of this format, including the REST variant for anyone preferring JSON and header authentication, are documented at /docs-api, viewable without any signup. Anyone who wants to test the reseller model before writing any code can start with the reseller link, explained at /revenda, which uses the exact same supplier behind it.

Sources

• Stripe | Idempotent requests: https://docs.stripe.com/api/idempotent_requests
• MDN Web Docs | HTTP response status codes: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
• Banco Central do Brasil | Pix: https://www.bcb.gov.br/estabilidadefinanceira/pix