Home / Algorithmic Risk / API Failure
Operational riskIntermediate

API Failure

API failure is the operational risk that the interface between a strategy and the broker or exchange breaks or misbehaves, through rejections, timeouts, rate-limit blocks, disconnections or stale acknowledgements, leaving the algorithm uncertain whether its orders actually reached the market.

Quick answer: API failure is the operational risk that the interface between a strategy and the broker or exchange breaks or misbehaves, through rejections, timeouts, rate-limit blocks, disconnections or stale acknowledgements, leaving the algorithm uncertain whether its orders actually reached the market.

In simple words

API failure is when the connection between your algorithm and your broker breaks or behaves badly. Orders get rejected, time out, or hit rate limits; sometimes you send an order and never learn whether it was accepted. The core danger is uncertainty: the algorithm thinks it exited a position but the order never went through, so it is still exposed without knowing it. Handling this well is less about clever code and more about never assuming an order worked until the broker confirms it did.

Purpose

This page exists because an algorithm's link to the market is a fragile, rate-limited channel it does not control, and mishandling a rejection, timeout or lost acknowledgement can leave positions in a state the strategy does not even realise it is in.

Professional explanation

The API is a channel you do not control

Unlike your own hardware, the broker API and the exchange behind it are outside your control, and they fail in their own ways: scheduled downtime, overload during volatile opens, order rejections for margin or price-band reasons, rate-limit throttling, and outright disconnection. During exactly the volatile moments when you most need to act, expiry, a gap open, a news event, the API is most likely to be slow or rejecting, because everyone else is hammering it too. A strategy must therefore be designed assuming the channel is unreliable and busiest when it matters most, rather than assuming every order sails through instantly.

The lost-acknowledgement problem

The most insidious API failure is not a clean rejection but silence: you send an order and the acknowledgement never arrives, so you do not know whether it was received, filled, or dropped. Naively resending risks a duplicate fill and a double position; not resending risks leaving the intended action undone. The correct handling is idempotency and reconciliation: tag orders with unique client IDs so a resend cannot double-execute, and query the broker for actual order and position state rather than assuming. An algorithm that treats send as equivalent to done will eventually build a phantom position it does not know it holds.

Rate limits and the runaway-retry trap

Broker and exchange APIs enforce limits on orders and requests per second, and breaching them gets you throttled or temporarily blocked, potentially at the worst moment. A common self-inflicted failure is the retry storm: an order fails, the code retries immediately, the retry also fails, and a tight loop floods the API until it blocks the account entirely. Robust clients use bounded retries with backoff, a cap on total attempts, and awareness of the rate budget, so a transient error does not escalate into a self-imposed lockout. In India, exchange and broker order-per-second limits are explicit, and a poorly written algo can exhaust them and lock itself out precisely when it needs to manage risk.

Rejections carry information, handle each kind

Not all failures are equal, and treating every rejection the same is a mistake. A margin rejection means the account cannot support the order and blindly retrying is pointless and possibly harmful; a price-band or circuit rejection means the exchange will not accept the price and the order must be repriced, not resent; a transient network timeout may genuinely warrant a careful retry. A strategy should parse the rejection reason and respond appropriately, because a retry loop that ignores a margin or circuit rejection wastes the rate budget and can mask a real problem, such as the account being closer to a margin call than the algo assumes.

Degrade safely when the API is down

When the API is unreachable for a sustained period, the strategy faces a book it can no longer manage through the normal channel, and its default behaviour matters enormously. The safe design does not keep firing blind; it recognises the outage, stops generating new orders, and falls back to protection that does not depend on the live API, principally protective orders already resting at the exchange and a broker-side auto square-off. It also alerts a human to take over via an independent route. The dangerous design keeps trying to trade through a dead channel, building up queued or duplicate orders that all execute at once when the connection returns, often into a market that has already moved.

Practical example

Illustrative example (Indian market)

A strategy on Rs 5,00,000 sends an order to exit one Nifty lot as the market falls. The API call times out with no acknowledgement; the code, written naively, assumes the exit failed and resends. In fact both orders reach the exchange, and the strategy ends up short one lot instead of flat, an unintended reversed position it does not know it holds. Nifty then rallies 200 points, and the phantom short loses about Rs 15,000 on top of the original trade. A correct client would have tagged each order with a unique client ID so the exchange rejected the duplicate, and would have queried actual position state before resending, discovering it was already flat. The loss came entirely from mishandling a lost acknowledgement, not from a bad market view.

Indian broker APIs such as those used for retail algos publish explicit rate limits (orders and requests per second) and have well-known load stress at 9:15 open and on weekly-expiry afternoons. An algo that retries aggressively can breach the order-per-second limit and get throttled or blocked by the broker exactly during an expiry-day move, leaving it unable to place the very risk-reducing orders it needs, which is why bounded retries and broker-side square-off matter.

Limitations

  • The API and exchange are outside your control, so some outages can only be planned around, not prevented
  • Reconciliation reduces but cannot fully remove the window of uncertainty during a lost acknowledgement
  • Broker-side square-off runs on the broker's rules and timing, which may not match your loss budget
  • Rate limits mean that in a fast market you may be unable to send all the orders you want in time
  • Idempotency depends on the broker honouring client order IDs, which not all interfaces do consistently

Common mistakes

  • Treating an order as done the moment it is sent, before the broker confirms it
  • Blindly resending on a timeout without unique client IDs, causing duplicate or reversed positions
  • Retrying instantly in a tight loop until the API throttles or blocks the account
  • Handling every rejection the same way instead of parsing margin, circuit and timeout reasons distinctly
  • Continuing to fire orders into a dead API so they all execute at once when it returns
  • Assuming the API will be fast and available during expiry, gaps and news, when it is most stressed

Professional usage

Professional execution systems assume the API is unreliable and busiest when it matters most. They tag every order with a unique client ID for idempotency, reconcile actual order and position state with the broker rather than trusting send-equals-done, and use bounded retries with backoff and a rate budget to avoid self-inflicted throttling. They parse rejection reasons and respond specifically, and when the channel is down they stop firing blind, leaning on exchange-resting protective orders and broker-side square-off while alerting a human through an independent route.

Key takeaways

  • API failure is the broker or exchange link breaking, and its worst form is uncertainty over whether an order worked
  • Never treat an order as done until confirmed; use unique client IDs so a resend cannot double-execute
  • Use bounded retries with backoff to avoid a retry storm that throttles or locks out the account
  • When the API is down, stop firing blind and fall back to exchange-resting stops and broker square-off

Frequently asked questions

What is API failure in algorithmic trading?
API failure is the operational risk that the interface between your strategy and the broker or exchange breaks or misbehaves, through rejections, timeouts, rate-limit blocks, disconnections or stale acknowledgements. Its core danger is leaving the algorithm uncertain whether its orders actually reached the market.
What is the lost-acknowledgement problem?
It is when you send an order but the acknowledgement never arrives, so you do not know whether it was received, filled or dropped. Naively resending risks a duplicate fill and a double position; not resending risks leaving the action undone. The fix is unique client IDs plus reconciliation against the broker.
How do I avoid duplicate orders after a timeout?
Tag every order with a unique client ID so the exchange rejects a duplicate, and query actual order and position state before resending rather than assuming. An algorithm that treats sending an order as equivalent to it being done will eventually build a phantom position it does not know it holds.
What is a retry storm and how do I prevent it?
A retry storm is when a failed order is retried immediately, the retry also fails, and a tight loop floods the API until it throttles or blocks the account. Prevent it with bounded retries, exponential backoff, a cap on total attempts, and awareness of the broker's rate budget.
Should I retry every rejected order?
No. Rejections carry information: a margin rejection means the account cannot support the order and retrying is pointless, a circuit or price-band rejection needs repricing not resending, and only a transient timeout may warrant a careful retry. Parse the reason and respond specifically.
What should an algo do when the API goes down?
Recognise the outage, stop generating new orders, and fall back to protection that does not need the live API, principally exchange-resting stops and broker-side auto square-off, while alerting a human by an independent route. It should not keep firing blind into a dead channel.
Why is the API most likely to fail when I need it most?
Because volatile moments, expiry, gap opens, news events, are when everyone hammers the API at once, so it is most likely to be slow, throttling or rejecting exactly then. A strategy must be designed assuming the channel is unreliable and busiest when it matters most.
How does API failure differ from system failure?
System failure is your own hardware, power, network or software breaking, which you control through redundancy. API failure is the broker or exchange connection breaking, which is largely outside your control and handled through retries, reconciliation, idempotent orders and broker-side stops.
What are rate limits and why do they matter?
Broker and exchange APIs cap the number of orders and requests per second, and breaching the cap gets you throttled or temporarily blocked. This matters because a poorly written algo can exhaust the limit through aggressive retries and lock itself out precisely when it needs to manage risk.
What is idempotency in order handling?
Idempotency means a resent order cannot execute twice, achieved by tagging each order with a unique client ID the broker recognises. It lets a client safely resend after an uncertain timeout without risking a duplicate fill, which is central to handling lost acknowledgements correctly.
Can API failure reverse my position?
Yes. If an exit times out and the algo blindly resends, both orders may execute, flipping a long into a short it does not know it holds. This is a classic lost-acknowledgement failure, and it is why reconciliation and unique client IDs matter as much as the market view.
Does broker-side square-off protect me during an API outage?
Partially. A broker-side auto square-off can flatten a position when margin is breached even if your API is down, but it runs on the broker's rules and timing, not your loss budget, so it is an outer safety net rather than a substitute for your own controls.
How should I test my algo's handling of API failures?
Inject the failure modes: simulated timeouts, rejections of each type, disconnections and rate-limit blocks, and verify the algo reconciles rather than assumes, does not retry-storm, and degrades safely. Handling that works only on the happy path is untested for the conditions that actually cause losses.

Voice search & related questions

Natural-language questions people ask about API Failure.

What is API failure in trading?
It is when the connection between your algorithm and your broker breaks or misbehaves, orders get rejected, time out, or you never learn whether they went through.
Why are lost order confirmations dangerous?
Because you do not know if the order worked. If you resend, you might double your position; if you do not, you might be exposed. Either way you are trading blind.
How do I stop my algo sending duplicate orders?
Give every order a unique ID the broker recognises, so a resend cannot execute twice, and always check your real position before resending after a timeout.
Why does my algo get blocked by the broker?
Usually a retry storm. It retries a failed order over and over, breaches the orders-per-second limit, and the broker throttles or locks it out. Use bounded retries with backoff.
What should my algo do if the broker connection dies?
Stop sending new orders, lean on stops already resting at the exchange and any broker auto square-off, and alert you to take over. Do not keep firing into a dead link.
Should I retry every rejected order?
No. A margin rejection means retrying is pointless, a circuit rejection needs a new price, and only a timeout may deserve a careful retry. Read the reason before you resend.
Why is the broker slowest exactly when I need it?
Because volatile moments like the open, gaps and expiry are when everyone hammers the API at once. Plan for the connection to be busiest and flakiest right when it matters most.

Sources & references

    Last reviewed 12 July 2026. Educational content only — not investment advice. Markets and rules change; verify current conventions with SEBI, NSE/BSE and your broker.

    ← Previous
    System Failure
    Educational content only — not investment advice. Examples use illustrative numbers and simplified models. Risk-management techniques reduce but never remove risk, and trading derivatives involves substantial risk of loss. See our Risk Disclosure and SEBI Disclaimer.