Three lines in a changelog can break a trading bot faster than any market selloff. That is the short story of the September 9 IBKR Web API update, and most of the damage lands on code that assumed an API contract never moves. Interactive Brokers paced historical data, deleted a scanner endpoint from the docs, and quietly removed a search parameter. If your bot hard-coded any of those three, check your IBKR Web API logs today.
Quick Answer
On September 9, 2026, Interactive Brokers published a Web API changelog entry with three changes that matter to automated traders. Pacing on /iserver/marketdata/history is now capped at 10 requests per second or 50 requests per minute, the /hmds/scanner endpoint is deprecated and removed from the documentation, and the secType parameter has been removed from /iserver/secdef/search, according to the IBKR Web API changelog for September 9, 2026. Nothing in that IBKR Web API entry gives a sunset date or a drop-in replacement for the scanner, so bots that scan on a loop need a rewrite, not a patch.
Key Takeaways
- The 50 requests per minute ceiling on /iserver/marketdata/history is the real constraint, not the 10 per second burst. Sustained, that is 0.833 requests per second, per the September 9, 2026 Web API changelog.
- Historical requests are also capped at five concurrent in-flight calls, so a bot can break the rules by frequency or by parallelism, according to IBKR’s Web API changelog and pacing documentation.
- /hmds/scanner is gone from the docs. The supported surface is /iserver/scanner/run at one request per second, with /iserver/scanner/params limited to one request every 15 minutes.
- Exceeding a limit returns HTTP 429, and an offending IP can land in a 10-minute penalty box, with repeat offenders facing a block until it is resolved.
- Production documentation lists a global cap of 10 requests per second per authenticated session, while the Web API staging page describes 50 per second globally. Staging behavior does not predict production behavior.
- The TWS API got its own update on September 24, 2026, consolidating the limitations page, per the TWS API changelog. Version 10.51 fixed reqPositions exchange field values.
- The direction is clear: the old HMDS surface of the IBKR Web API is being retired in favor of iserver endpoints.
What changed in the IBKR Web API on September 9, 2026?
Three things changed, and all three are breaking changes if your code was written in a hurry. The IBKR Web API documentation changelog entry dated September 9, 2026 modified pacing on historical market data, deprecated the HMDS scanner endpoint, and removed the secType parameter from security definition search.
Here is what each one actually does to a running bot.
1. Historical data pacing. Requests to /iserver/marketdata/history are now capped at 10 requests per second or 50 requests per minute. Read that twice. Those two numbers are not the same constraint. A bot that fires 10 requests, sleeps a second, fires 10 more, will satisfy the per-second rule and blow through the per-minute rule inside 12 seconds.
2. The scanner endpoint vanished from the docs. IBKR says /hmds/scanner is now considered deprecated and has been removed from the documentation. No sunset date. No replacement endpoint named in that entry. No stated response-code transition. For a production system, documentation removal is an API-contract warning, not a courtesy note.
3. secType is out of secdef search. The secType parameter has been removed from /iserver/secdef/search because the value was deprecated. If your request to https://api.ibkr.com/v1/api/iserver/secdef/search always appends symbol plus secType, test whether the server ignores the field, rejects the request, or behaves differently between environments.
The common thread: every one of these three changes punishes a bot that assumes the web API will never move under it.
None of this is an outage. The changelog describes documentation and pacing changes, not downtime. Code that stops working after an IBKR Web API change usually stops because it was brittle. That distinction matters when you are deciding whether to blame the broker or your own request layer.
What is the IBKR Web API, and how does it fit with TWS and FIX?
IBKR’s API lineup is the set of programmatic interfaces Interactive Brokers LLC offers for placing orders, pulling market data, and managing an account without touching a screen. Three offerings sit under that umbrella: the IBKR Web API (REST plus WebSocket), the TWS API (a socket connection through Trader Workstation or the IB Gateway), and FIX, aimed at institutional order flow. The IBKR API home page on IBKR Campus is the front door for all three.
A quick mechanical primer, because the jargon trips people up. Conid is short for contract identifier, the numeric ID IBKR assigns to every instrument. You look up a conid once, then use it everywhere: in an order payload, in a historical bars request, in a WebSocket subscription message like smd+CONID+fields. Symbols change, conids do not. Any bot that keys off ticker strings instead of the conid is one corporate action away from a wrong order.
IBKR Web API vs TWS API vs FIX
Pick the interface based on where your code runs, not on which one looks newest. The feature comparison below is the decision most builders get wrong on day one.
| Offering | Best for | How it connects | Market data | Typical cost to use |
|---|---|---|---|---|
| IBKR Web API | Cloud bots, web apps, mobile, no desktop dependency | REST and WebSocket over HTTPS, via OAuth or the Client Portal Gateway | Snapshots, streaming quotes, historical bars from iserver endpoints | No separate API fee; market data subscriptions billed to the account |
| TWS API | Local desktop strategies, options chains, deep order types | Socket to running TWS or IB Gateway on port 4001 or 7497 | Streaming and historical via tick and bar callbacks | No separate API fee; same data subscription rules |
| FIX | Institutional and enterprise order routing at scale | FIX session, sponsored access | Order flow focused, market data usually external | Institutional arrangement; confirm with IBKR |
Full specs live in the IBKR Web API documentation on interactivebrokers.com, and the Web API trading overview on IBKR Campus covers order placement, order reply messages, and account endpoints. Older tutorials call this surface the IBKR Client Portal API, because it was first reached through the Client Portal Gateway; it is the same REST interface now documented as the Web API. If your stack is Python and local, start with our walkthrough of the Interactive Brokers TWS API setup and quirks.
Who actually uses the IBKR Web API
IBKR segments API users into retail, day or algorithmic traders, institutional desks, enterprise clients, and third party developers building tools on top of the platform. The needs diverge fast.
- Retail, day or algorithmic traders: one account, one or two strategies, Python or Node, usually running on a cheap VPS. This group feels pacing changes hardest because they poll everything.
- Institutional: multiple accounts, allocation models, FIX sessions, compliance logging.
- Enterprise: white-label or embedded brokerage, high order volume, service-level expectations.
- Third party developer: building a scanner, a dashboard, or a bot other people pay for. One deprecated endpoint becomes a support queue.
If you are in the first group, the honest question is whether you need a broker API at all yet. Our breakdown of what to check before you automate trades with an AI bot covers that decision before you write a line of code.
IBKR Web API pricing and what the costs really are
There is no separate subscription fee for the IBKR Web API itself. You pay for market data, you pay commissions, and you pay the opportunity cost of your own debugging time. Options data, US equity depth, and futures bundles are account-level subscriptions, so an options-heavy bot costs more to feed than an equities bot pulling delayed quotes.
Two costs people forget. First, market data lines: concurrent streaming symbols are capped per account, so a 400-symbol watchlist is not a subscription problem, it is an architecture problem. Second, currency. Funding in the currency you trade avoids paying conversion spreads on every fill, which matters for a bot trading non-US instruments. For current numbers, check IBKR’s pricing pages directly rather than trusting any blog, including this one.
Is the IBKR Web API good for beginners, or only professionals?
It is usable by a motivated beginner and unforgiving of a careless one. The learning curve is real: session management, order reply messages that require a confirmation POST before an order is live, and documentation spread across the Web API docs, the TWS API docs, and IBKR Campus.
Decision rule: if you cannot explain what a conid is, what an order reply message does, and what HTTP 429 means, you are not ready for live order routing. Build it in a paper trading account at Interactive Brokers first, run it for 30 sessions, then talk about real money. Paper trading is the cheapest insurance in this business.
If you would rather have an AI assistant write and debug that request layer with you, our walkthrough on connecting the IBKR Web API to Claude shows the setup step by step, including a working IBKR Web API example for pulling bars and placing a paper order.
Which bots break when the scanner endpoint disappears?
Any bot whose universe selection calls /hmds/scanner is now building on an endpoint IBKR has removed from its own documentation. The supported path is /iserver/scanner/run, and the pacing is different enough that a naive port will trip limits immediately.
The pacing table in IBKR’s Web API changelog and usage documentation lists /iserver/scanner/run at one request per second and /iserver/scanner/params at one request every 15 minutes. That second number is the one that catches people. Scanner params describe the available filters and scan codes. They almost never change. A bot that fetches params at the top of every scan cycle will get rate limited within minutes, then retry, then earn a 429, then retry again, and then meet the penalty box.
Who is exposed:
- Custom Python bots that copied an old HMDS scanner example from a forum post.
- Third party tools and dashboards that scan the market on a schedule and never audit their endpoint list.
- Anything that rescans the full universe every cycle instead of scanning rarely and monitoring a short list.
Who is fine: bots that take a static watchlist, resolve each symbol to a conid once, and stream quotes over WebSocket. Boring architecture survived the update untouched.
The important operational split is discovery versus monitoring. Scanner calls find candidates. Snapshots and WebSocket streams watch the ones you selected. IBKR’s documentation describes snapshots as needing a preflight activation call and streaming market data through smd plus conid messages. A bot that scans once at the open, picks 25 names, and then streams those 25 all session uses a fraction of the request budget of one that rescans every 60 seconds.
If you are shopping for tools that already handle this plumbing, our list of fully automated AI trading bots is a reasonable starting point for seeing which ones connect to a broker versus which just email you ideas.
How do the new market data history pacing limits affect your bot?
The practical effect is that sustained IBKR Web API historical data collection is now capped at roughly 0.83 requests per second, because 50 requests per minute is the binding long-run limit even though 10 requests inside one second is permitted as a burst. Add the separate cap of five concurrent in-flight historical requests and backfilling a large universe becomes a scheduling problem.
Run the arithmetic before you redesign anything. At 50 requests per minute, pulling one daily-bar series each for 500 symbols takes 10 minutes of pure request time, assuming zero failures and zero retries. Pulling five timeframes for the same universe takes 50 minutes. That is not a bug, that is the new budget, and any strategy that needs fresh bars for 500 names every five minutes is simply not compatible with this endpoint.
| Endpoint | Documented limit | What it means for a bot |
|---|---|---|
| /iserver/marketdata/history | 10 per second or 50 per minute | Sustained ceiling is 50 per minute; plan backfills |
| /iserver/marketdata/history concurrency | 5 concurrent requests | Cap your worker pool at 5, not 20 |
| /iserver/scanner/run | 1 per second | Scan on a schedule, not on every tick |
| /iserver/scanner/params | 1 per 15 minutes | Cache it on startup and leave it alone |
| Global session (production docs) | 10 per second per authenticated username | Shared across every endpoint you call |
Two mistakes to avoid. First, implementing the limit as a one-second sleep loop. That satisfies the per-second rule and violates the per-minute rule. Use a shared token bucket or leaky bucket limiter that every worker thread draws from, sized to the minute constraint. Second, retry loops without backoff. IBKR’s documentation is explicit that exceeding a pacing limit produces HTTP 429, that an offending IP address may be placed in a 10-minute penalty box, and that repeated violations can lead to a block until resolved. An uncontrolled retry loop converts a brief error into a 10-minute outage, and then into a permanent one.
Also note the environment discrepancy. Production documentation describes a global limit of 10 requests per second per authenticated session, while the staging documentation describes 50 per second globally and keeps a 10 per second restriction on the Client Portal Gateway. Tuning your rate limiter against staging and shipping it to production is how you discover the difference at the worst possible moment.
IBKR’s stated design rationale is resource protection: global session limits, endpoint limits, concurrency limits, and market data line constraints. This is shared backend capacity management, not an anti-bot measure. Your bot is not being singled out. It is being queued.
How do you update ibkr api python code for the changes?
Fix it in four passes, plus monitoring: audit your endpoint list, replace the scanner call, rebuild your rate limiter around the minute ceiling, and strip secType from secdef search. None of this needs a framework rewrite, and most bots are a one-afternoon job.
Step 1: grep your codebase. Search for hmds, scanner, secType, and marketdata/history. Every hit is a decision point. If anything still calls another /hmds endpoint, treat it as the next one in line for removal.
Step 2: migrate discovery to /iserver/scanner/run. Fetch /iserver/scanner/params exactly once on startup, cache the scan codes and filters in memory or on disk, and never call it again inside a loop. Then run scans at a human cadence: once at the open, once midday, once before power hour. Store the resulting conid list.
Step 3: rebuild the rate limiter. One shared limiter, not one per thread. Size it to 50 per minute for history. Cap the history worker pool at five. Add exponential backoff on 429 with a minimum wait that respects the 10-minute penalty window, and log every non-200 response with the endpoint, status code, and timestamp.
Step 4: clean up the request builders. Remove secType from your /iserver/secdef/search calls. A GET to https://api.ibkr.com/v1/api/iserver/secdef/search with the symbol alone should return the contract list; verify the conid you pick is the one you expect, since dropping a filter widens results. While you are in there, confirm your order path still handles order reply messages correctly, because an order is not live until the confirmation reply is answered.
Step 5: add drift monitoring. This is the step almost nobody does. Alert on any non-200 response rate above your normal baseline, on unexpected schema fields, and on documentation changes. Subscribe to the IBKR Web API changelog. Deprecations show up there as documentation edits, so if you are not watching the changelog, the market is your monitoring system, and that is an expensive one.
For a deeper foundation on structuring this kind of code, see our guide to Python algorithmic trading for retail traders and our overview of how AI trading platforms connect to a broker account.
What should investors watch next?
Watch the changelog cadence, the remaining HMDS endpoints, and the TWS API limitations page. The direction of travel is consolidation onto iserver, and each removal arrives as a documentation edit rather than a deadline.
Specific things on the radar:
- Remaining HMDS surface. /hmds/scanner left the IBKR Web API docs in September 2026. Assume anything else under that prefix is on borrowed time and stop building new code against it.
- TWS API limitations. The TWS API changelog shows a September 24, 2026 update consolidating the limitations page, and the 2026 production release notes list version 10.51 fixing reqPositions exchange field values. Position reconciliation bugs are exactly the kind of thing that quietly corrupts a risk calculation.
- FIX changes. If you route institutional flow, the FIX changelog deserves the same monitoring discipline as the Web API one.
Top 5 favorite features of the IBKR Web API
The IBKR Web API and its siblings earn their reputation on breadth, not polish. These five features are why serious builders keep tolerating the rough edges.
- Instrument coverage. Stocks, options, futures, bonds, funds, and FX across dozens of global markets through one account and one conid system. Almost no retail-accessible API comes close.
- Three interfaces, one account. Run a cloud bot on the IBKR Web API and a desktop options strategy on the TWS API against the same trading account.
- Real order types. Bracket orders, trailing stops, algos, and conditional logic exposed programmatically, not just market and limit.
- A genuinely free paper environment. Full API access against simulated fills, which is where every strategy should live first.
- Documentation plus training. The Web API documentation, the TWS API docs, Traders’ Academy courses with quizzes and sample assignments, and the IBKR Quant blog, which publishes technical pieces including work on a new synchronous wrapper for the TWS API. See the IBKR Quant API development category for the latest IBKR Quant articles.
Where the IBKR API documentation lives, and what sits around it
The canonical IBKR Web API reference sits on interactivebrokers.com under /docs/web-api, with the campus-side Web API documentation hub and the IBKR Campus changelog mirror covering release history. Traders’ Academy adds structured API courses on the same campus site.
One practical note: scraping the docs at speed is a fast way to get an IP throttled, so cache the pages you use locally instead of hitting them from your bot.
What we like, and what we don’t like
The IBKR Web API, with TWS behind it, is the most capable retail-accessible broker API available, and also the one most likely to make you read a changelog on a Saturday. Both things are true at once.
What we like:
- Breadth of instruments and markets through a single account and conid namespace.
- Order type depth that actually supports real risk management, including brackets and trailing stops.
- A free, full-featured paper account for development.
- Published pacing limits, so you can engineer against documented numbers rather than guess.
What we don’t like, specifically:
- Deprecations arrive as documentation edits. The September 9 entry gave no sunset date, no replacement endpoint, and no response-code transition for /hmds/scanner. That is a real drawback for anyone running production code.
- Documentation inconsistency between environments. Production says 10 requests per second globally; staging says 50. Two numbers for the same concept in the same documentation set is a trap.
- Session management is fragile on the Client Portal Gateway path. Keep-alive handling and re-authentication are the most common sources of silent failure for Web API bots.
- Rate-limit punishment is harsh. A 10-minute IP penalty box is a long time when you hold an open position.
What do real users say about the IBKR Web API?
The sentiment among automated traders is consistent: capable, not pleasant. The most-quoted version of that view, from r/algotrading, is blunt.
“honestly I just use interactive brokers, the api is kinda messy but it works once you get it set up.” u/absurd_atheism, r/algotrading
That is the whole ibkr api reddit consensus in one sentence. Messy, then stable. The traders who struggle are the ones who never finish the setup phase properly: no shared rate limiter, no response logging, no changelog monitoring. The traders who stop complaining are the ones who treated the integration as infrastructure instead of a weekend script.
Competitors and alternatives for automated trading
If the IBKR Web API’s complexity outweighs its breadth for your strategy, the main alternatives are Alpaca for US equities and options, Tradier for options-focused REST access, and Tradestation or Schwab for order routing with narrower global coverage. None of them match IBKR on instrument breadth, and that is usually the tradeoff you are making.
| Broker API | Strongest for | Main limitation | Cost structure |
|---|---|---|---|
| IBKR Web API and TWS API | Global stocks, options, futures, FX in one account | Session complexity, documentation drift, harsh rate limits | No API fee; market data subscriptions plus commissions |
| Alpaca | Clean REST docs, fast onboarding, US equities and options | Limited non-US coverage, fewer order types | Free tier available; paid data tiers |
| Tradier | Options chains and order routing via simple REST | US only, thinner futures support | Commission or flat-rate plans |
| Tradestation | Desktop plus API hybrid, futures access | Smaller developer community | Commission based |
Decision rule: choose IBKR if you trade more than one asset class or more than one country. Choose a simpler REST broker if you trade US equities only and value shipping speed over coverage. For a wider view, see our comparison of which brokers offer a real trading API and our look at what algorithmic trading AI gets wrong for retail traders.
Our Take
The September 9 IBKR Web API update did not break good bots. It breaks bots with no rate limiter, no endpoint audit, and no monitoring. That is a design problem wearing a changelog costume.
Treat the broker API as a dependency that changes without asking. One shared limiter sized to the 50 per minute history ceiling. One scan on a schedule, then a small monitored conid universe over WebSocket. Logs on every non-200 response. A calendar reminder to read the changelog monthly. Systems over hacks, and the system here is boring on purpose.
If you want the broader reality check on what automation does and does not deliver, our analysis of whether AI trading bots actually make money is the counterweight to any API tutorial, and the Interactive Brokers tool profile covers the broker side of the equation.
Next step: audit your request layer this week. Search your code for hmds, secType, and marketdata/history. Fix the three things the changelog named, then add the monitoring that would have caught them early.
Built a bot that survived the update, or one that didn’t? We catalogue automated trading tools and how they connect to broker APIs. Submit your bot for review.
Conclusion
The September 9, 2026 IBKR Web API update was small, specific, and easy to miss. Pacing on historical data, a deleted scanner endpoint, one removed search parameter. Bots that fall over do so because they poll without limits, scan without caching, and monitor nothing.
Do three things this week: cap your history worker pool at five and your limiter at 50 per minute, cache scanner params once instead of per cycle, and log every non-200 response with its endpoint and status code. Then put a monthly reminder on your calendar to read the changelog.
This article is education, not financial advice, and nothing here is a recommendation to buy or sell any security.
Your market edge starts with the right tool. Stay alpha.
Frequently Asked Questions
What changed in the IBKR Web API on September 9, 2026?
Per the IBKR Web API changelog dated September 9, 2026, /iserver/marketdata/history is now capped at 10 requests per second or 50 per minute, /hmds/scanner is deprecated and removed from the documentation, and the secType parameter was removed from /iserver/secdef/search.
Is the IBKR Web API free?
Interactive Brokers charges no separate subscription fee for API access, including the Web API, the TWS API, and the paper trading environment. You still pay standard commissions and any market data subscriptions your strategy needs, such as options or futures depth. Those data fees are billed to the account, not to the API itself.
Does IBKR offer API access?
Yes, through three interfaces: the Web API using REST and WebSocket over HTTPS, the TWS API using a socket connection to Trader Workstation or IB Gateway, and FIX for institutional order routing. All three run against the same trading account and the same conid contract identifiers.
What is the IBKR Client Portal API?
The IBKR Client Portal API is the earlier name for what IBKR now documents as the Web API: a REST and WebSocket interface reached either through the locally run Client Portal Gateway or through OAuth. Requests go to paths such as /iserver/accounts and /iserver/marketdata/history.
What are the IBKR Web API rate limits?
As of the September 9, 2026 changelog, /iserver/marketdata/history allows 10 requests per second or 50 requests per minute, with five concurrent history requests maximum. /iserver/scanner/run allows one per second and /iserver/scanner/params one every 15 minutes. Breaching a limit returns HTTP 429.
Why does my IBKR bot keep failing?
Many failures are not platform outages. They are session expirations on the Client Portal Gateway, HTTP 429 rate-limit responses, or calls to endpoints removed from the documentation, such as /hmds/scanner. Check your response logs for status codes before assuming an outage, and confirm against IBKR's own system status page.
Where is the IBKR API documentation?
The Web API documentation sits on interactivebrokers.com under /docs/web-api, with the changelog at /docs/web-api/changelog and the TWS API docs at /docs/tws-api. IBKR Campus mirrors much of it alongside Traders' Academy API courses. Bookmark the changelog, since deprecations appear there first.
Can I automate trading with Interactive Brokers?
Yes. You can place, modify, and cancel orders programmatically through the Web API or the TWS API, including bracket orders and trailing stops. Order submission requires answering order reply messages before the order goes live. Build and test in a paper account first, since a logic error routes real orders instantly.
Contributing writer at AI Stock Trading Bots.
