ib_insync vs ib_async: Which IBKR Python Wrapper to Use

The most-used Python wrapper for Interactive Brokers' API was ib_insync. It was archived read-only on March 14, 2024, following the passing of its author, Ewald de Wit. The maintained community successor is ib_async, developed by the ib-api-reloaded organization. This page explains what changed, how compatible the two libraries are, and which to use for new and existing projects. No investment advice, no affiliate links — neutral guidance for researchers choosing their stack.

Head-to-Head Comparison

Both libraries wrap Interactive Brokers' TWS API and Client Portal Gateway using Python's asyncio model. The distinction is entirely one of maintenance status.

Four Points of Nuance

1. The transition was due to the author's passing, not abandonment

ib_insync was actively maintained and widely used. Its archival was not a product decision or a case of a maintainer losing interest — Ewald de Wit passed away in early 2024, and the repository was archived shortly after. This context matters for how you interpret the codebase: ib_insync is not broken or deprecated in a technical sense. It is frozen at v0.9.86, a stable release that worked well. The library's asyncio design and core architecture are sound. The problem is that Interactive Brokers' API evolves, Python versions evolve, and there is no longer anyone to apply updates. ib_async was created precisely to continue that work.

2. API compatibility: ib_async is largely a drop-in replacement

ib_async was designed to be API-compatible with ib_insync. The core objects — IB, Contract, Order, Trade, Ticker — follow the same interfaces. The asyncio event loop model, the ib.connect() flow, and the callback/event patterns are preserved. Most ib_insync codebases can migrate to ib_async by changing the import statement and resolving any Python version requirements. Non-trivial differences and breaking changes are documented in ib_async's release notes. For projects with extensive ib_insync usage, review those notes before migrating — but expect the migration to be measured in hours, not days.

3. Python version requirement: 3.10+ is a real constraint

ib_async requires Python 3.10 or newer. ib_insync's last stable version works with Python 3.6+. If your trading system still runs Python 3.7, 3.8, or 3.9, migrating to ib_async requires a Python version upgrade as a prerequisite. Python 3.10 introduced structural pattern matching and improved typing features; ib_async uses the improved async/await semantics available from 3.10 onwards. For teams on older Python versions, the migration has two steps: Python upgrade first, then ib_insync → ib_async. Python 3.10+ is the current standard for production trading systems, so this is a worthwhile upgrade regardless.

4. ib_async is actively developed, not just patched

ib_async is not merely applying bug fixes to a frozen codebase. The ib-api-reloaded organization makes ongoing changes to keep pace with IBKR's API updates, resolve Python compatibility issues, and improve the library. v2.0.1 (June 2025) reflects a significant version bump from ib_insync's v0.9.x series. Any new IBKR API features — new order types, new data endpoints, authentication changes — will be implemented in ib_async and not in ib_insync. Over time, the divergence between the two libraries will increase as IBKR's API evolves.

Best for Whom

• All new IBKR Python projects: ib_async. No exceptions. ib_insync will not receive bug fixes or compatibility updates.
• Existing ib_insync code that works and is stable: Evaluate migration when you next touch the codebase, or when you hit a compatibility issue. There is no urgency for code that is not actively developed — ib_insync will not spontaneously break.
• Existing ib_insync code that is actively developed: Migrate now. Any new feature work or bug fixes you need will be easier on ib_async's maintained codebase.

When Neither Fits

Both ib_insync and ib_async wrap IBKR's API specifically. If you want to avoid IBKR's authentication complexity entirely, Alpaca (alpaca-py, REST + WebSocket, API key, no session management) covers US stocks, ETFs, options, and crypto with a significantly simpler integration path. For code-first backtesting that connects directly to IBKR live without a separate wrapper, QuantConnect/LEAN has native IBKR broker connection support via its Lean CLI. IBKR's official Python, Java, C++, and C# clients are also available for teams that prefer the official SDK over a community wrapper — but those clients are lower-level than ib_insync/ib_async and require more manual event loop management.