Idempotency in order APIs: how one retry quietly becomes two paid orders

AutoSMO — Tue, 01 Sep 2026 23:48:10 +0000

AI disclosure: this article was written with the assistance of AI, then reviewed and edited before publishing.

If you've ever wired a client to an API that places orders — payments, shipping, ad spend, anything that moves money — you've met this bug, or you will:

The request times out. Your client retries. The first request had actually succeeded. Now the customer has two orders and one complaint.

It's not a rare edge case. On any system with real traffic, timeouts are constant, and a naive "retry on failure" turns a network hiccup into a duplicate charge. Here's why it happens and how to make it stop.

The trap

A timeout is not a failure. It's the absence of an answer. The order may have gone through, may have failed, or may be processing right now — your client has no idea. So the instinct to retry is exactly wrong for any endpoint that isn't idempotent:

# DON'T do this on a create/charge endpoint
def place_order(payload):
    for attempt in range(3):
        try:
            return api.post("/orders", json=payload, timeout=10)
        except Timeout:
            continue   # <-- each retry may create ANOTHER order

A POST /orders has no natural idempotency: the server can't tell your retry apart from a genuine second order. So it happily creates both.

Fix 1 — idempotency keys (if the API supports it)

Stripe popularised this and it's the clean solution: the client generates a unique key per logical operation and sends it with every attempt. The server stores the result against that key and returns the same result for repeats instead of doing the work twice.

key = str(uuid4())               # one key per logical order
def place_order(payload):
    for attempt in range(3):
        try:
            return api.post("/orders", json=payload,
                            headers={"Idempotency-Key": key}, timeout=10)
        except Timeout:
            continue   # safe now: same key = same order, never a second one

The important detail: the key is generated once, outside the retry loop. Generate it inside and you're back to square one.

Fix 2 — reconcile, don't blind-retry (if it doesn't)

Plenty of APIs have no idempotency key. Then the rule is: a timeout goes to a reconciliation step, not a retry. Before sending again, ask the API what actually happened:

def place_order_safe(payload, client_ref):
    try:
        return api.post("/orders", json={**payload, "ref": client_ref}, timeout=10)
    except Timeout:
        # don't resend — check first
        existing = api.get("/orders", params={"ref": client_ref})
        if existing:
            return existing        # it did go through
        return api.post("/orders", json={**payload, "ref": client_ref})

Attach your own client_ref to every order, and a timeout becomes a lookup instead of a gamble. If the API can filter by your reference, you can always tell "already created" from "never created."

The rule of thumb

GET / DELETE by id — naturally idempotent, retry freely.
PUT — usually idempotent, retry is fine.
POST that creates or charges — never blind-retry. Use an idempotency key, or reconcile by your own reference first.

Timeouts are not the exception on a busy system; they're the weather. Design the create path assuming every request might be sent twice — because eventually, one will be.

What's your approach — idempotency keys, client-side dedup, or something else? Curious how others handle the reconcile step when the API gives you nothing to key on.

Integrating an SMM Panel API (v2): a practical guide for building reseller tools

AutoSMO — Wed, 19 Aug 2026 16:46:46 +0000

AI disclosure: this article was written with the assistance of AI, then reviewed and edited before publishing.

Full disclosure: I build AutoSMO, and I use its public v2 API as the live example in this guide. The idempotency, catalogue-refresh and partial-order patterns below apply to any order API, not just this one.

If you're building a social-media growth storefront, a reseller bot, or an automation that places engagement orders, you'll almost certainly integrate an SMM panel API. Most panels — including AutoSMO, which I'll use as the live reference here — expose the same v2 API shape, so what you learn on one carries over to the rest.

This is a practical walkthrough: the core calls, working code, and the four mistakes that turn a clean integration into refunds and chargebacks.

The shape of a v2 SMM API

A v2 panel API is a single endpoint that takes a POST with your key, an action, and parameters. The actions you actually need:

services — the full catalogue: IDs, names, per-1000 rate, min/max, refill terms.
add — place an order (service ID + link + quantity).
status — poll an order (spent charge, start count, remains, state).
balance — your account balance.
refill — request a refill on an eligible order.

That's the whole surface. Everything else is your own business logic on top.

A first request, end to end (Python)

import requests

API = "https://autosmo.com/api/v2"
KEY = "YOUR_API_KEY"  # server-side only — see below

def call(action, **params):
    r = requests.post(API, data={"key": KEY, "action": action, **params})
    r.raise_for_status()
    return r.json()

# 1. Read the catalogue and pick a service
services = call("services")
service = next(s for s in services if s["service"] == "6758")

# 2. Validate against the service's own limits BEFORE ordering
qty = 1000
assert int(service["min"]) <= qty <= int(service["max"]), "quantity out of range"

# 3. Place the order
order = call("add", service=service["service"], link="https://instagram.com/p/…", quantity=qty)
print("order id:", order["order"])

# 4. Poll it to completion
status = call("status", order=order["order"])
print(status)   # {'charge': '0.72', 'start_count': '...', 'remains': '...', 'status': 'In progress'}

Node is the same three moves — services → validate → add → poll status.

The four mistakes that cost real money

1. The key is a wallet, not a config detail. It authorises spending. It belongs in server config — never in front-end JavaScript, a mobile bundle, or a public repo. Anyone holding it can place orders against your balance. Rotate it the moment it touches a browser, a chat, or a screenshot.

2. add has no idempotency key — so never auto-retry it. A timeout does not mean the order failed. If your client blindly retries, one customer order becomes two paid orders. Queue timeouts for a human to reconcile against status, don't fire them again automatically.

3. Your catalogue copy goes stale. Rates, limits and availability change when suppliers change theirs. If you cache services and forget to refresh on a schedule, you'll sell at prices you no longer have. Poll it; don't hardcode it.

4. Map remains into your refund logic. Orders come back partial when the provider delivers some but not all of the quantity. remains tells you how much didn't land. Marking a partial delivery as "complete" to your own customer is the fastest way to earn a chargeback — reflect the shortfall honestly.

Balance-aware queuing

Because there's no invoice step, add only succeeds while the balance covers the order. For any real volume, poll balance and pause your queue before it hits zero, rather than letting orders fail mid-batch:

if float(call("balance")["balance"]) < estimated_cost:
    pause_queue()   # top up, then resume

Test one real order before you switch traffic over

Place the smallest order the catalogue allows, poll it to completion, and confirm your side matches charge to the cent. That single end-to-end test teaches you more than any doc — and it's the difference between "it returns 200" and "it actually fulfils."

The full call list, parameters and example responses for the reference implementation are on the AutoSMO API page — it's a live v2 endpoint you can read your integration against.

Building reseller tooling on top of an SMM API? The gotchas above (idempotency, stale catalogue, partial mapping) are where most integrations quietly leak money — worth wiring up front.

DEV Community: AutoSMO