Interactive Brokers API Developer: Hiring Guide and Checklist

To hire an Interactive Brokers API developer, hand candidates a written specification and judge them on how they handle disconnects, paper-account acceptance and code handover, not on promised returns. The developer does not need your live password or 2FA codes: development and testing run in a paper account, and you switch the bot to live trading yourself. If live access is ever required, IBKR can set up a limited-permission user. This guide covers the specification, the IBKR steps only you can complete, an acceptance checklist for the contract, code ownership and red flags.

Note: This article describes the legal situation in general terms as of the date below. It is not legal or tax advice and does not replace a review of your specific case by a lawyer or tax advisor. All information without guarantee of completeness or timeliness.

How hiring an Interactive Brokers API developer works

An Interactive Brokers (IBKR) trading bot reads market data, applies fixed rules, sends orders and monitors positions. Python bots usually connect through the TWS API, a socket interface served by Trader Workstation (TWS) or the lighter IB Gateway. The REST-based Web API is the alternative; IBKR Web API vs TWS API compares the two. The code is rarely the hard part. Projects fail on vague rules, missing account permissions, tests that ignore costs and unclear ownership.

A structured project produces one document per phase. The table shows a typical example. The page on Interactive Brokers bot development in Python describes a concrete offer along these lines, including acceptance on the paper account.

Skip phase 1, and phase 6 turns into an argument about what was ordered.

What to put in a trading bot specification

A bot can only implement what is described unambiguously. The strategy comes from you. The developer translates it, asks about gaps and flags technical consequences, but does not judge whether it will make money.

Typical example (an illustration, not a recommendation): “buy when the trend turns” is an idea. “After a 15-minute bar closes above the highest high of the previous 20 bars, send one limit order at that close, valid for two bars, canceled if unfilled” is a testable rule.

• Instruments: exchange, currency and, for futures, the roll rule.
• Signals: formulas, data source, bar size, closed or still-forming bars.
• Orders: type, limit offset, time in force, partial fills, rejections, modifications.
• Size and risk limits: sizing formula, maximum position, daily loss limit, maximum open orders, kill switch. The position size calculator shows how a fixed risk per trade becomes a quantity.
• Schedule: trading windows, IBKR server resets, holidays, daylight saving time.
• Failure behavior: disconnects, missing data, unclear order status, restart with open positions.
• Logging: a machine-readable order log, one line per order event (audit script below).
• Technical frame: hosting, Python version, library, alerts and request pacing. By default the TWS API allows 50 requests per second (100 market data lines divided by 2), according to IBKR.

IBKR’s own Python API requires Python 3.11 or later, and IBKR’s download page lists it only in the Latest API package, not in Stable (as of November 2026). ib_async, which its maintainers describe as the replacement for ib_insync, implements the protocol itself, requires Python 3.10 or later and does not need IBKR’s ibapi package; see ib_async vs ib_insync. Pin the accepted versions so every update is deliberate.

IBKR account setup for API trading: your checklist (as of November 2026)

Only the account holder can complete these steps, mostly in IBKR’s Client Portal. Do them before development starts. According to IBKR’s documentation:

Paper trading and acceptance: a checklist template for the contract

A backtest only counts if it models your account’s costs: commissions under your pricing plan, exchange and regulatory fees, spread and realistic slippage. The report should state data period and source, how many parameter variants were tried and which period was kept out of the optimization; the best of a hundred variants is often just curve fitting.

The paper account tests the technology, not the strategy. IBKR states that paper-account execution is not indicative of real trading conditions. It also advises trying an order idea manually in TWS first: what TWS does not support will not work through the API either.

Acceptance checks the specification point by point against observed behavior. Use the table as a template for the contract. Every line is a must; the test period, thresholds and alert channel come from your specification.

Criterion 8 can be checked mechanically if the specification requires a JSON Lines order log: one line per event with order_id, event (submitted, acknowledged, partial_fill, filled, canceled or rejected), qty on submission and fill_qty on fills. Field names are an example. The script flags unreadable lines and unknown events, events after a final status, orders without a final status, fills that exceed the order quantity or do not add up to it on filled, and an empty log. Tested with Python 3.9 and 3.12, standard library only, on sample logs including fractional quantities; it reads a local file, connects to nothing and sends no orders.

# order_log_audit.py: checks an order log (JSON Lines). Standard library only;
# reads a local file, connects to nothing and sends no orders.
import json
import sys
from decimal import Decimal

EVENTS = {"submitted", "acknowledged", "partial_fill", "filled", "canceled", "rejected"}
FINAL = {"filled", "canceled", "rejected"}


def audit(lines):
    orders, issues = {}, []
    for n, line in enumerate(lines, 1):
        if not line.strip():
            continue
        try:
            e = json.loads(line, parse_float=Decimal)  # exact fractional sums
            oid, event = str(e["order_id"]), e["event"]
            qty, fill = e.get("qty", 0), e.get("fill_qty", 0)
            numbers = all(isinstance(x, (int, Decimal)) for x in (qty, fill))
            if event not in EVENTS or not numbers:
                raise ValueError
        except (ValueError, KeyError, TypeError):
            issues.append(f"line {n}: not a valid log entry")
            continue
        o = orders.get(oid)
        if o is None:
            if event != "submitted":
                issues.append(f"line {n}: {oid} starts with '{event}'")
            orders[oid] = {"qty": qty, "filled": fill, "state": event}
            continue
        if o["state"] in FINAL:
            issues.append(f"line {n}: {oid} has '{event}' after '{o['state']}'")
            continue
        o["filled"] += fill
        o["state"] = event
    if not orders:
        issues.append("no orders in the log")
    for oid, o in orders.items():
        if o["state"] not in FINAL:
            issues.append(f"{oid}: no final status, last event '{o['state']}'")
        if o["filled"] > o["qty"] or (o["state"] == "filled" and o["filled"] != o["qty"]):
            issues.append(f"{oid}: filled {o['filled']} of {o['qty']}")
    return orders, issues


if __name__ == "__main__":
    with open(sys.argv[1], encoding="utf-8") as f:
        orders, issues = audit(f)
    print(f"{len(orders)} orders, {len(issues)} issues")
    for issue in issues:
        print(" -", issue)
    sys.exit(1 if issues else 0)

Run it with python3 order_log_audit.py orders.jsonl. Exit code 1 signals issues, so it also fits automated tests. An order still open at the end of the log is flagged; whether that is a defect depends on its time in force.

Code written with AI coding assistants goes through the same acceptance. Language-model components, if any, must not be able to place orders without a human approving them.

Who owns the trading bot code: copyright, GPL and market data

Paying for custom code does not by itself make you its owner. The contract should say who owns what:

• United States: according to the US Copyright Office, a commissioned work is a “work made for hire” only if it falls into one of nine listed categories and both parties sign a written agreement saying so; software is not among them. A copyright transfer must be in writing and signed (17 U.S.C. § 204(a)), so contractor agreements usually contain an explicit assignment.
• Germany: copyright itself cannot be transferred. The developer grants rights of use; where the contract does not list the types of use, its purpose decides which are covered (sections 29 and 31 of the Copyright Act).

The clause should cover ownership or rights of use, modification by others, distribution, components the developer keeps and licenses to you, the handover format and confidentiality of your strategy.

Since TWS API 10.49 of August 3, 2026, IBKR releases the TWS API under the GNU General Public License (GPL); ib_async is BSD-licensed. According to the GPL FAQ, a modified version may be used privately or within an organization without releasing it, while handing copies to others counts as distribution. Separately, IBKR’s API download page prohibits using the TWS API to pass market data to third parties without IBKR’s prior written approval. If you plan to share or sell the bot, or show its market data to other people, have both points checked by a lawyer first.

Risks and red flags when hiring a trading bot developer

A bot executes rules faster and more consistently than a person; it does not make a strategy better. A rule set that only looks good because of curve fitting tends to lose money live, and a bot then loses it automatically. With leveraged products such as futures, short options or forex, losses can exceed the capital deployed; a total loss is possible.

• Login: IBKR recommends “Never lock Trader Workstation” and “Auto restart” for API users, but its weekly reauthentication cycle, starting on Mondays, requires a manual login, and IBKR requires 2FA for all users. IBC, the community tool long used to automate logins, was retired on September 1, 2026, and its repository is archived; see IB Gateway in Docker after IBC.
• Maintenance: IBKR requires the current Stable or Latest release of TWS or IB Gateway and of the TWS API, so the software needs updates after delivery.
• Human error: wrong parameters, live instead of paper, a missed weekly login.

Red flags when choosing a developer: promises of returns or win rates; “proven” strategies for sale or a profit share; requests for the password or 2FA codes of your live account; offers to run the bot on your account and decide for you; no specification, test report, acceptance record or source code; no verifiable identity; pressure to decide quickly.

Questions to ask an Interactive Brokers API developer

Before the first call, write your rules on one page (instrument, signal, order, size, exit, risk limits), work through the IBKR checklist above and decide whether the software stays with your own account or may later be shared. Then ask every candidate the same questions:

• Which API and library will the bot use, and why?
• How does the bot handle disconnects, restarts and position reconciliation?
• What does the acceptance test contain, and who signs it off?
• What is delivered at handover: repository, documentation, runbook, test record?
• Who owns the code, and which components does the developer keep?
• Who has access to which account, and who switches the bot on?
• What happens after go-live: updates, the weekly login, reactions to alerts?

Effort depends on the number of instruments, the complexity of the rules, the test scope, the interface and whether monitoring is included. Running costs in your own account, such as commissions, market data and a server, come on top. A reliable quote follows a conversation about your written specification, not a price list. Cost drivers, and whether to hire at all or build it with AI, are covered in how much a trading bot costs.

Frequently asked questions

How do you hire an Interactive Brokers API developer?

Write a one-page specification of your rules and risk limits, and prepare your IBKR account first: IBKR Pro, an API-compatible 2FA method, a separate username for the bot, market data subscriptions and the Market Data API Acknowledgement. Then ask every candidate the same questions about reconnects, position reconciliation, acceptance testing and code ownership. Put an acceptance checklist into the contract, accept the bot in the paper account and switch it to live trading yourself.

Does Interactive Brokers allow automated trading bots?

Yes. IBKR describes the TWS API as a way to automate operations you would otherwise perform manually in Trader Workstation, such as placing orders and monitoring positions. You need an opened and funded IBKR Pro account and a current release of TWS or IB Gateway. There is a notable exception: according to IBKR, Interactive Brokers Canada does not allow clients to submit orders for products on Canadian exchanges through their own API application.

Does an IBKR API developer need your password or 2FA codes?

In most cases, no. Development and testing run in the paper account, and you keep the live start and the weekly login. If live access is really needed, IBKR’s Account Configuration team can set up a limited-permission user, for example without withdrawal or direct trading access. Anyone who asks for the password or 2FA codes of your main user is showing a clear warning sign.

Is paper trading enough to accept an IBKR bot?

It is enough to accept the technology, not to judge the strategy. IBKR states that paper-account execution is not indicative of real trading conditions. A paper run shows whether connection, order logic, failure handling, kill switch and logs work. A sound acceptance combines a backtest with realistic costs, a paper run with deliberately provoked failures and a cautious live start with small position sizes that you activate yourself.

Can an IBKR trading bot run without any manual login?

Not entirely. For the daily cycle, IBKR recommends the settings “Never lock Trader Workstation” and “Auto restart” for API users. The weekly reauthentication cycle, which starts on Mondays, still requires a manual login, and IBKR requires 2FA for all users. IBC, the community tool long used to automate logins, was retired on September 1, 2026. Agree on who performs the weekly login and how the bot alerts you when it is missing.

Who owns the source code of a custom trading bot?

Whoever the contract says, provided it says so clearly. In the US, a copyright transfer requires a signed written instrument, and custom software from an independent contractor is generally not a work made for hire. Under German law, copyright itself cannot be transferred; the developer grants rights of use whose scope should be spelled out. Settle ownership, modification, distribution, licenses such as the GPL of the TWS API and the handover format before work starts.

How much does it cost to hire an Interactive Brokers API developer?

There is no meaningful flat price. Effort depends on the number of instruments, the complexity of the rules, the test and acceptance scope, the interface and whether ongoing monitoring is included. Running costs in your own IBKR account come on top, mainly commissions, market data subscriptions and possibly a server. A reliable quote requires a conversation about your written specification.

Sources and status

• TWS API: Requirements (account, versions, minimum Python release) — Interactive Brokers (retrieved November 3, 2026)
• TWS API: Supported Two Factor Authentication (2FA) — Interactive Brokers (retrieved November 3, 2026)
• TWS API Limitations (purpose of the API, paper trading, Canadian residents) — Interactive Brokers (retrieved November 3, 2026)
• TWS API: Logging into multiple applications — Interactive Brokers (retrieved November 3, 2026)
• Market Data: Multiple Users (limited-permission user for developers) — Interactive Brokers (retrieved November 3, 2026)
• Market Data Requirements (IBKR Pro, USD 500, Market Data API access) — Interactive Brokers (retrieved November 3, 2026)
• Market Data API Acknowledgement — Interactive Brokers (retrieved November 3, 2026)
• Order Types: Notes and Limitations (paper trading, testing in TWS) — Interactive Brokers (retrieved November 3, 2026)
• TWS API: Pacing Limitations (50 requests per second, error code 100) — Interactive Brokers (retrieved November 3, 2026)
• TWS API: Daily and Weekly Reauthentication — Interactive Brokers (retrieved November 3, 2026)
• TWS API Changelog: August 3, 2026 release (10.49, GPL) — Interactive Brokers (retrieved November 3, 2026)
• TWS API software download (Stable and Latest packages, note on disseminating market data) — Interactive Brokers (retrieved November 3, 2026)
• ib_async (README, license, requirements; repository description “replaces ib_insync”) — ib-api-reloaded on GitHub (retrieved November 3, 2026)
• IBC (project retirement notice) — IbcAlpha on GitHub (retrieved November 3, 2026)
• Circular 30: Works Made for Hire — U.S. Copyright Office (retrieved November 3, 2026)
• Copyright Law of the United States, Chapter 2 (17 U.S.C. § 204) — U.S. Copyright Office (retrieved November 3, 2026)
• Copyright Act (Urheberrechtsgesetz), English translation, sections 29 and 31 — Federal Ministry of Justice (gesetze-im-internet.de) (retrieved November 3, 2026)
• Frequently Asked Questions about the GNU Licenses — Free Software Foundation (retrieved November 3, 2026)

As of November 2026. Third-party rules, prices and APIs may have changed since; the providers' current documentation and the official texts are authoritative.

Need an Interactive Brokers bot built to a clear specification? Get in touch — a free intro call clarifies the rules, the test and acceptance scope and how the bot will be operated. More: Trading bot development for Interactive Brokers and MetaTrader 5.