API Retries Without Duplicate Orders
Retrying a failed vendor API call can create duplicate orders, licenses or renewals. This guide explains the patterns that reduce that risk.
Apivom Team
The core problem with naive retries
The short answer is: attach a stable request identifier before the first call, keep a local idempotency record, cap your retry attempts, apply back-off between each one, and route anything still unresolved to a human review queue. That sequence reduces the risk of duplicate orders even when vendor APIs return ambiguous responses. The rest of this article explains each step and where the pattern has real limits.
When a vendor API call fails mid-flight, your system faces a binary choice: give up or try again. Giving up leaves a gap in the business record. Trying again without precautions can create 2 orders, 2 license seats or 2 renewal charges for the same transaction.
The root cause is uncertainty. A timeout or network error does not tell you whether the vendor processed the request before the connection dropped. Your system has to assume it might have, and act accordingly.
Stable request identifiers
The first safeguard is a stable, unique identifier you attach to every outbound request before you send it. If the call fails and you retry, you send the exact same identifier. The vendor system — if it supports idempotency — recognises the identifier and returns the original result instead of processing the request again.
Key properties of a good request identifier:
- Generated once, before the first attempt
- Tied to the business event, not the HTTP call
- Stored durably so retries use the same value
- Scoped to a time window the vendor specifies
Without a stable identifier, each retry looks like a new request. With one, the vendor can deduplicate on its side.
Idempotency records on your side
Vendor support for idempotency varies across the Autodesk, Microsoft and Adobe ecosystems. Some endpoints honour a client-supplied key; others do not expose enough state to confirm whether a prior call succeeded. You cannot rely on vendor behaviour alone.
Your integration layer should maintain its own idempotency record for every outbound request. That record captures the request identifier, the payload hash, the attempt count, the last response code and the resolved status. Before any retry, your system checks the record. If a completed status is already stored, the retry is skipped.
This local record also gives operations teams a clear audit trail. A sales leader asking "did that renewal go through?" gets a direct answer from the record, not a guess based on email confirmations.
Retry windows and back-off
Not every failure warrants an immediate retry. A rate-limit response from a vendor API means the system is healthy but busy; retrying in milliseconds makes the problem worse. A server error may indicate a transient fault that clears in seconds, or a deeper outage that lasts hours.
A practical retry strategy combines 3 elements:
- Exponential back-off — each retry waits longer than the last, reducing pressure on the vendor endpoint
- Jitter — a small random delay spreads retries from concurrent requests so they do not all hit the vendor at the same moment
- A hard retry limit — after a defined number of attempts the system stops and routes the event to a human review queue
The retry window should stay inside the vendor's idempotency key expiry. If your key expires before the final retry, you need a new key and a fresh deduplication check.
Rate-limit handling
Rate limits are a normal operating condition in vendor APIs, not an error state. Your integration should read the rate-limit headers the vendor returns and schedule the next attempt accordingly, rather than firing retries at a fixed interval.
When multiple operations — a quote, a license activation and a renewal — are queued at the same time, a priority order matters. Renewals expiring today rank above new quotes. An integration layer that processes all requests with equal urgency will exhaust its rate-limit budget on lower-priority work and delay the calls that matter most.
Apivom Atlas is an API integration gateway. It provides a single place to manage outbound calls to vendor endpoints, which means retry rules, back-off settings and priority logic can be configured in one location rather than scattered across per-vendor scripts.
Observable status trails
Retry logic running silently in the background creates a different problem: nobody knows what happened. Operations leaders need to answer questions like "is that Microsoft order still pending?" or "did the Adobe renewal retry succeed overnight?"
An observable status trail records every state transition for a request:
| State | Meaning |
|---|---|
| Pending | Request created, not yet sent |
| Attempted | Sent, awaiting response |
| Rate-limited | Vendor asked us to wait |
| Retrying | Back-off timer running |
| Confirmed | Vendor returned a success response |
| Failed | Retry limit reached, routed to review |
This trail should be readable by operations staff, not just developers. If the status language requires a developer to interpret it, the trail is not doing its job.
Where it falls short
Retry patterns solve the mechanical problem of uncertain network calls. They do not solve everything.
Unclear business rules are outside scope. If your team has not agreed whether a failed renewal should auto-retry or wait for a sales rep to review, no retry configuration will make that decision for you. The pattern executes the rule; it does not define it.
Weak source data causes failures that retrying cannot fix. A quote with a missing customer identifier will fail on the first attempt and every subsequent one. The integration layer will correctly stop after the retry limit and route the event to review, but the underlying data problem still needs a human.
Vendor-side opacity is a real constraint in some ecosystems. When a vendor API does not return enough state information to confirm whether a prior call was processed, your local idempotency record can only reflect what your system knows. If the vendor processed the request but returned an ambiguous response, a human review step is the safest resolution path — not another automated retry.
Apivom Atlas is an API integration gateway. Retry rules still need clear business decisions, reliable source data and vendor responses that expose enough state. The gateway gives you a consistent place to apply the pattern; it cannot compensate for gaps in any of those 3 areas.
Putting the pattern together
A reliable retry design follows a clear sequence. Generate a stable identifier before the first call. Store an idempotency record locally. Send the request with the identifier attached. On failure, classify the error before deciding whether to retry. Apply exponential back-off with jitter. Check the idempotency record before each retry. Stop at the retry limit and route unresolved events to a review queue. Record every state transition in a trail that operations staff can read.
This sequence helps keep the business record clean even when vendor APIs behave unpredictably. It also makes the integration auditable: every order, quote, license or renewal has a documented history of what was attempted and what resolved.
The pattern requires discipline to implement consistently across multiple vendor endpoints. Each ecosystem — Autodesk, Microsoft, Adobe — has its own rate-limit behaviour, idempotency support and error response format. A single integration layer that applies the pattern in one place reduces the maintenance burden compared to custom retry logic written per vendor.
Review Apivom Atlas at https://apivom.com/products/atlas.