API Documentation

Overview

The Boostero API is a single POST endpoint that gives you the whole service catalog, order placement, order status, refills, cancellations and your account balance in JSON. It is built for resellers running their own storefront, agencies placing orders for clients, child panel owners, and developers wiring social media delivery into an existing product.

It follows the standard SMM panel v2 convention, so an integration written against another panel on that convention usually works here by changing two things: the endpoint URL and the key. Parameter names, the action names and the JSON response shapes are the ones you already know.

Getting started

Four steps from nothing to a live order.

1. Generate an API key on your Account page. The key identifies your account and carries your balance and your prices.
2. Call services once and store the result. It returns every service with its numeric ID, rate, min and max. You need the ID to order, and min and max to validate a quantity before you send it.
3. Place one small test order with add, using the min quantity from step 2 so the test costs as little as the service allows. The response returns an order ID.
4. Read that order with status. Once you are polling more than a handful, switch to the batched form and read up to 100 IDs in one call. See polling for the pattern.

Authentication

Every request carries your key in the POST body as the key parameter. There is no header auth, no OAuth step and no token to refresh. Because the key travels in the body of a server-side request, it must never appear in code that runs in a browser, in a mobile app bundle, or in a public repository. If a key is exposed, regenerate it on the Account page; the old key stops working immediately.

Rate limits

The platform does not publish a per-key or per-IP request limit, and responses carry no rate limit headers. Measured on 4 September 2026, 170 sequential requests sent at roughly nine per second all returned HTTP 200 with no throttling, no error and no measurable slowdown across the run.

What does degrade is concurrency rather than rate. Twenty-five simultaneous requests all succeeded, but the slowest of them took 2.5 seconds against about 100 milliseconds when the same calls were sent one after another. The practical guidance that follows from this is:

• Send requests sequentially and space a polling loop at about one second between calls. That is well inside what the endpoint absorbs and leaves headroom if a limit is introduced later.
• Keep concurrent in-flight requests in single figures. Parallelism is what makes responses slow, not volume.
• Batch order IDs. One status call with 100 IDs replaces 100 calls and is the single largest reduction you can make.
• Stop polling an order once it reaches a final state. Completed and canceled orders do not change again.

Quick start

The same call in four languages: fetch the service list. Swap action and add the parameters from the reference below to make any other call. All four examples are on this page at all times.

Longer, runnable versions of all four, with the error handling around them, are on GitHub: github.com/Boostero-Smm-Panel/boostero-docs. That repository also documents every method, the error table and the measurements below in one Markdown file, which is easier to read side by side with your editor than a web page is.

There is also a Postman collection with all ten calls, their parameters and an example response for each: documenter.getpostman.com/view/58247943/2sBYAyupWB. Import it and set the api_key variable to your own key; it ships empty.

curl -X POST "https://boostero.com/api/v2" \
  -d "key=YOUR_API_KEY" \
  -d "action=services"

<?php
$ch = curl_init('https://boostero.com/api/v2');
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query([
    'key'    => 'YOUR_API_KEY',
    'action' => 'services',
]));
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);

$services = json_decode(curl_exec($ch));
curl_close($ch);

import requests

r = requests.post(
    "https://boostero.com/api/v2",
    data={"key": "YOUR_API_KEY", "action": "services"},
    timeout=30,
)
services = r.json()

const res = await fetch("https://boostero.com/api/v2", {
  method: "POST",
  headers: { "Content-Type": "application/x-www-form-urlencoded" },
  body: new URLSearchParams({ key: "YOUR_API_KEY", action: "services" }),
});
const services = await res.json();

Drip-feed

Drip-feed splits one order into a series of smaller ones released on a timer, so delivery arrives gradually instead of all at once. The add action takes two extra parameters for it: runs, the number of separate deliveries, and interval, the gap between them in minutes.

A worked example. To deliver 1,000 followers over ten hours rather than in one burst, send quantity=100 with runs=10 and interval=60. That is ten runs of 100, one every sixty minutes. Note that quantity is the size of each run, not the total: the total delivered is quantity multiplied by runs, and your balance is charged for the total.

Drip-feed is not available on every service. The services response exposes a dripfeed field where the platform provides it, and that field is the value to check before offering the option to your own customers. Sending drip-feed parameters to a service that does not support it returns an error rather than silently placing a normal order.

Webhooks and polling

No webhooks. Order status is polled, up to 100 IDs per request.

This is a property of Perfect Panel, the software this panel runs on, not a Boostero limitation: the specification has no webhook, callback or push mechanism in any of its ten calls. Measured 2026-09-11 against the Perfect Panel demo API.

The polling pattern that works

The status action accepts a list of order IDs and returns a keyed object with one entry per ID, up to 100 IDs in a single request. A loop built on that costs very little:

• Keep a local set of order IDs that are not yet in a final state.
• Poll that set in batches of up to 100 rather than one call per order.
• Space the batches about one second apart, and keep concurrent requests low. See rate limits for the measurements behind that.
• Remove an order from the set as soon as it reaches a final state. Completed and canceled orders will not change again, and polling them is pure waste.
• Back off when nothing is moving. An order that has not changed in an hour does not need a check every second.

In practice a reseller with a thousand open orders needs ten requests per polling cycle, not a thousand, which is comfortably inside anything the endpoint has been measured to absorb.

If you would rather not build the loop

A child panel is the alternative. It gives you a complete storefront on your own domain with your own prices and your own customer accounts, and it handles ordering and order status for those customers without you writing or maintaining an integration. Use the API when you are plugging delivery into a product you already have; use a child panel when the storefront is the product.

Errors

Errors arrive as JSON with an error key. The HTTP status is not uniform, and this matters when you write the handler: authentication failures come back as 401 and an unknown action as 404, while validation failures come back as 200 with the error in the body. Check both. Reading only the status code hides every validation error; reading only the body hides a rejected key.

Which check fires first

The endpoint returns one error, not a list, so when a request is wrong in more than one way only the first failure is reported. The order was measured on 4 September 2026 by sending requests that were deliberately wrong in several ways at once:

1. Service ID. An unknown service is rejected before anything else is looked at.
2. Quantity range. A request with a bad quantity, a bad link and a cost over balance returns the quantity error.
3. Balance. A request with a bad link and no funds returns the funds error.

The practical consequence when debugging: fixing the error you were shown can reveal another one underneath it. Validate quantity against min and max on your side before sending, and the second round trip disappears.

The link is not validated

There is no fourth check. Once the service exists, the quantity is in range and the balance covers the cost, the order is created and the link is taken as given. Tested on 4 September 2026: the literal string notaurl was accepted as a link and returned an order ID rather than an error.

This is the single most useful thing to know before you write an integration against this endpoint. A typo in a link does not come back as an error you can catch; it comes back as an order ID, the balance is charged, and the order fails later at the provider where your code is no longer watching. The supplier cancels it and the amount goes back to the balance, so the cost is the delay rather than the money. Validate links on your side before sending them: check the URL parses, check the host matches the platform the service targets, and check it is a profile link where the service needs a profile and a post link where it needs a post. Nothing downstream will do it for you.

Security

• Store the key in an environment variable or a secrets manager, never in source code, and never in a file that reaches version control.
• Never put the key in anything that runs in a browser or ships inside a mobile app. Every request must originate from your server.
• Use one key per system. If a key has to be replaced you then replace one integration rather than all of them at once.
• Rotate on suspicion rather than on schedule. A key that has appeared in a screenshot, a support thread, a log file or a shared terminal is already exposed.
• Regenerating on the Account page invalidates the previous key immediately, so plan the swap before you press it.