Trading options through the Interactive Brokers API
The first version takes a weekend. You connect to the gateway, qualify a contract, place an order, watch it fill, and it feels solved. This page is about the part after that: what a script has to survive before you trust it with real money on a 0DTE position, and what that costs to keep alive.
The Interactive Brokers API, in three parts
The TWS API
The socket protocol you speak to a running Trader Workstation or IB Gateway. It is what most automation uses, and the Interactive Brokers API documentation you will spend your time in.
The IBKR Web API
The Client Portal REST alternative, fronted by a gateway process you also run and keep authenticated. Different shape, same fundamental requirement: something of yours stays logged in. Sometimes searched as the Interactive Brokers REST API.
Interactive Brokers Python wrappers: ib_insync and ib_async
The official Interactive Brokers Python client is deliberately low-level, so most people reach for ib_insync, or its maintained successor ib_async, which put an asyncio-friendly surface over the request/response plumbing. They are good libraries. They solve the protocol, which turns out not to be the hard part.
The parts that break in production
Every item here is something we hit building on the same API, in roughly the order you hit them in.
- The gateway restarts every night
- IB Gateway has a scheduled restart, and it takes every connection with it. Anything holding a socket, a subscription, or an in-flight order needs to notice, back off, reconnect, and re-establish what it was doing. Loops that assume a live connection simply stop, usually silently.
- A stalled event loop looks exactly like a dead socket
- The obvious health check is a periodic request with a timeout, reconnecting when it misses. Ship that and you get reconnect flapping, because a busy event loop misses the probe too. Distinguishing 'my process is briefly overloaded' from 'the socket is gone' takes more than one missed beat, and getting it wrong costs you a minute of downtime at the worst possible time.
- 100 market data lines, and options eat them
- The default subscription budget is 100 concurrent instruments. One underlying across a useful strike range can consume all of it. You end up writing a priority scheme, positions first and working orders next, then rotating whatever you are scanning as the market moves.
- Every connection needs its own client ID
- Client IDs must be unique per connection, and a real system has several: market data, order placement, monitoring, each again for paper and live. Collisions do not fail loudly so much as behave strangely, and the debugging is unpleasant.
- Partial fills leave you holding half a position
- A multi-leg entry that fills two of four legs and then dies is not a rare case at 0DTE speed, and neither the API nor a naive script has an opinion about what to do next. Once the process that started it is gone, something still has to know an entry was in flight, what it achieved, and how to finish or unwind it.
- Greeks that keep up with the quote
- The greeks the broker sends arrive on their own cadence rather than with every quote, so at 0DTE speed they lag the price you are acting on. Computing them yourself means a pricing model plus an implied-volatility solver, fed by an underlying price you are also responsible for keeping fresh.
- Expiry is not a calendar date
- Derive today's expiry from the current date and you will select already-settled contracts in the window between the close and the evening session. The expiry you want is the one the session you are trading in targets, which is a different question from what day it is.
When you should keep your own code
Plenty of people should keep the scripts. If your strategy is unusual, or the building is part of why you enjoy this, a tool that imposes its own model of a trade will get in your way. The same goes for research work rather than a book of live positions.
The case for stopping is narrower. It arrives when the infrastructure has stopped teaching you anything, and when the thing standing between you and a change to your actual strategy is a reconnect bug you have already fixed twice.
What VolNinja is
The system described above, already built and already debugged against the parts of IBKR that misbehave. It runs on your machine, against your own IBKR account, with nothing routed through us.
Above it sits the layer that is tedious to write for yourself. Rules built from delta, time, the underlying and the state of your whole book, re-evaluated as the market moves. Strategies that run continuously and keep variables between evaluations. And a Risk Lab that simulates a position or your whole book, live, and estimates how likely each rule you attached is to fire before expiry.
It installs as a desktop app on Apple Silicon Macs and on Windows, runs in Docker on Linux or a VPS, and you reach it from a browser anywhere.