Why We Rebuilt the Reseller API
When we first opened the QuickAdvertise platform to resellers, the API was something we bolted on: a handful of endpoints that covered the basics and nothing more. It worked, but resellers who had outgrown manual ordering kept running into the same friction — no way to place many orders in one call, no clean way to know when an order had actually started, and error messages that told you something broke without telling you what to fix.
API v2 is our answer to those conversations. It is a ground-up revision of the reseller interface, built around three goals: fewer calls for the same work, clearer feedback when something goes wrong, and a foundation we can extend without breaking what already runs.
What’s New in API v2
The changes are grouped around the way a real reseller workflow actually looks — placing orders, tracking them, and reconciling them against a balance.
- Unified service catalogue. One endpoint returns the live list of services, their IDs, pricing rules and minimum/maximum quantities, so your storefront can stay in sync without hard-coding service IDs.
- Bulk order submission. Multiple orders can be submitted in a single request, with per-order results returned in the response, instead of firing off one request per line item.
- Idempotency keys. Retry a request safely after a timeout without risking a duplicate order — a small detail that removes a lot of support tickets.
- Webhook events. Instead of polling order status in a loop, you can subscribe to status-change events and react when an order moves to processing, in progress, completed or cancelled.
- Scoped API keys. Issue separate keys for your production storefront, your staging environment and read-only reporting, and revoke any one of them without disrupting the others.
- Structured error responses. Errors carry a machine-readable code and a human-readable message, so your integration can branch on the code rather than parse a sentence.
Ordering at Scale: Bulk and Idempotent Requests
The bulk endpoint is the change resellers notice first. If you run a storefront that receives several orders a minute during a campaign, sending them one at a time means your queue is only as fast as the slowest individual call. Batching them into a single request cuts round trips and keeps your order log in step with what your customers see.
Idempotency keys matter just as much in practice, even though they are invisible when everything works. Networks drop connections. Servers time out. Without a key, the safe choice after a failure is to not retry — which means a customer’s order silently never lands. With a key, you can retry the identical request and the platform will return the original result rather than creating a second order. For resellers who automate heavily, this is the difference between a monitoring alert you can trust and one you learn to ignore.
Webhooks and Order Tracking
Polling is wasteful and slow. If you check order status every thirty seconds, you are making thousands of calls a day for information that changes a handful of times. API v2 lets you register a webhook URL and receive a signed event whenever an order changes state.
A practical integration pattern looks like this:
- Submit the order and store the returned order ID against your own record.
- Return an acknowledgement to your customer immediately — do not block the checkout on delivery.
- Handle the webhook event when it arrives and update the customer-facing status.
- Fall back to a periodic reconciliation call to catch any event your endpoint missed while it was down.
That last step is not optional. Webhooks are best-effort delivery, and any well-built integration treats them as a fast path rather than the only path.
Sandbox Mode and Better Error Handling
Testing against live services is how resellers accidentally spend money. API v2 adds a sandbox mode where requests are validated and orders are simulated: your payload shape, service IDs and quantities are all checked, but nothing is dispatched. It is the right place to develop a new storefront integration or to reproduce a bug a customer reported.
Error handling got a similar treatment. A well-behaved API tells you whether the problem was yours or ours. In v2, validation failures, authentication problems, insufficient balance and rate-limit responses are all distinct codes, so your code can retry the ones worth retrying and surface the rest to a human. Rate limits are communicated in response headers so you can pace your requests instead of discovering the ceiling by hitting it.
Migrating From v1
Existing v1 integrations keep working — we are not switching the old interface off while resellers are still running it. The migration is incremental: move your service-catalogue sync first, since that is usually the least risky change, then adopt bulk ordering, and add webhooks when your order volume justifies the extra endpoint on your side. Our services overview covers what each delivery channel does if you are mapping v2 services back to your own catalogue.
If you are a reseller or SMM panel operator and want API v2 access for your account, or you want to talk through a migration plan, reach out through our contact page and our partner team will set you up with credentials and documentation. QuickAdvertise reseller accounts include the API at no extra cost, and we would rather walk you through the upgrade than have you guess at it.
One honest note on expectations: an API makes your workflow faster and more reliable, but it does not change what the underlying services can do. Delivery speeds, refill terms and platform policies are the same whether you order through the dashboard or through v2 — the API is plumbing, not a new product.
