Trading 212 API: What You Can Actually Build

If you want to automate against a Trading 212 account, or want to understand what a connected application can actually do on your behalf, the Trading 212 Public API is the right place to start. It is currently in public beta, under active development, and already capable enough to support a complete portfolio rebalancing workflow. This article covers what it can read, what it can execute, how authentication works, what the Pies endpoints expose and where they stand, what account types are in scope, and where the limits fall. The Trading 212 connection guide covers the user-facing experience for Acubic specifically; this article covers the API itself.

How authentication works

The Trading 212 API authenticates with an API key and secret pair, formatted as an HTTP Basic Auth header. You generate the key pair in the Trading 212 app under Settings, then API, then New API key. When a request is made, the application Base64-encodes the key and secret together and sends them in an Authorization header. There is no OAuth flow and no redirect to a Trading 212 login page.

This is different from the eToro authentication model. On eToro, a standard App Store integration authenticates via OAuth PKCE: the user authenticates directly on eToro's login page and eToro issues a scoped bearer token. Trading 212 skips that step entirely; the credential is a key pair you generate yourself, and it never requires the user's account password to leave their own device. Revoking the key in the Trading 212 app ends third-party access immediately, without any action from the application holding it.

IP address restriction is optional and available from the same settings panel where keys are generated. Restricting a key to one server IP means a leaked key cannot be replayed from anywhere else, which is a meaningful security improvement for server-side integrations that make calls from a fixed address. Acubic displays its server IP on the connection screen specifically so users can apply this restriction if they want to.

Two environments are available: a paper trading environment at demo.trading212.com for testing with no real capital at risk, and the live environment at live.trading212.com. The two are completely separate. Credentials from the demo environment cannot authenticate against the live one, and the rate limits and API surface are identical across both. The paper trading environment is the right place to confirm an integration works correctly before connecting a real account.

What the API can read

The read surface covers five main areas.

Account summary returns a breakdown of the account's cash position: funds available to trade, cash reserved for pending orders, cash held inside Pies, and investment metrics including current value, total cost, and realised and unrealised profit and loss. This is the right read for understanding the account's overall state before calculating what needs to change. Rate limit is one request every five seconds.

Positions returns all open positions on the account, with each position's ticker, quantity held, current market value, total cost, and unrealised profit and loss. A query parameter allows filtering to a specific instrument. Rate limit is one request per second, making it practical to poll at reasonable frequency during a rebalance run. For a rebalancing workflow, this is the read that tells you where the portfolio actually stands.

Pending orders returns all orders that have been placed but not yet filled, cancelled, or expired. A separate endpoint retrieves a specific order by its numeric ID. Knowing which orders are pending before computing a rebalance matters: a position in the process of being filled is already committed, and treating it as an open gap will produce a duplicate order for the same instrument.

Historical data is available across three streams: order history, dividend history, and transaction history. All three use cursor-based pagination with a maximum of 50 items per response and a rate limit of six requests per minute. A fourth path supports asynchronous CSV report generation: you submit a report request that specifies a time range and which data to include, receive a report ID, then poll until the status shows as finished and download the file. This is useful for building reconciliation tooling or account analytics outside the primary trading workflow.

Instrument and exchange metadata is available for looking up tradable instruments by ticker, ISIN, name, currency, and type, and for retrieving exchange working schedules. The instrument list is rate-limited to one request every fifty seconds, so it is designed to be cached rather than fetched on every rebalance. Symbol resolution for a large portfolio is far more efficient with a local cache than with per-request lookups.

What the API can execute

Four order types are available, which is a wider execution surface than the eToro API offers. All orders are placed by quantity, not by value. A sell order uses a negative quantity. Orders execute and settle in the primary account currency.

Market orders execute at the next available price. This is the order type used for straightforward rebalancing: buy or sell a quantity at whatever the current market will bear. An extended hours flag allows the order to be queued for execution outside standard trading sessions rather than being held until the market opens. Rate limit is fifty requests per minute, which is the most generous ceiling on the execution side. A twenty-position rebalance can fire all its orders within the first minute with headroom to spare.

Limit orders execute at a specified price or better: a buy limit fills at the stated price or lower, a sell limit fills at the stated price or higher. Two duration options are available. Day orders expire at midnight in the exchange's timezone if not filled. Good-till-cancel orders remain active until filled or explicitly cancelled. Rate limit is one request every two seconds.

Stop orders trigger a market order when the instrument's last traded price reaches a stated stop price. Stop-limit orders trigger a limit order instead when the stop is reached, which protects against the slippage a plain stop order incurs in a fast-moving market. Both types carry the same rate limit as limit orders. Any unfilled order can be cancelled by its numeric ID.

The API specification notes that all execution endpoints are currently not idempotent. Sending the same request twice may produce duplicate orders. An integration needs to track order IDs and avoid blind retries; checking for a pending order on the instrument before placing a new one is safer than assuming a second request is safe to fire.

The Pies API

The Trading 212 API includes endpoints for managing Pies: create, read, update, delete, and duplicate operations. In the official API specification, every one of these endpoints is marked as deprecated. They remain in the API for backwards compatibility but are no longer the recommended path for programmatic allocation management.

Acubic does not request the Pies permission in the key scope it documents for users, so it cannot interact with Pies on connected accounts even incidentally. This is a deliberate design choice. Pies are a fixed user-defined allocation bucket. Acubic's approach re-derives the target allocation on each rebalance cycle from current market data and the connected strategy's risk parameters, then trades only what has drifted. The two systems operate on different logic and do not mix cleanly on the same account. The required API key scope for an Acubic connection lists six permissions and omits both Pies permissions entirely. For more on how the rebalance trade construction works, the rebalancing model guide explains the mechanics in detail.

Account types and restrictions

The Trading 212 Public API works only with Invest and Stocks ISA accounts. CFD accounts are not supported, and the API provides no access to them regardless of how the key is scoped. If a user's primary Trading 212 account is a CFD account, the API cannot connect to it. There is no workaround for this through key permissions.

Multi-currency is not currently supported. All account, position, and result values in API responses are reported in the primary account currency. Orders execute in the primary account currency. For accounts holding instruments denominated in other currencies, the API reports values converted to the primary currency rather than showing per-currency breakdowns. This is a current beta limitation rather than a permanent architectural decision, but it is a real constraint for any portfolio that spans multiple base currencies.

There is a functional limit of fifty pending orders per ticker, per account. A rebalancing strategy that relies on many resting limit orders across a single instrument will encounter this ceiling before it approaches any rate limit.

What the API cannot do

There is no money movement function. The API has no withdrawal endpoint, no deposit trigger, and no account-to-account transfer mechanism. An application operating through the API reads equity positions and places equity orders. Cash stays in the Trading 212 account regardless of what the application sends. Withdrawals and deposits happen through Trading 212's own interface, outside the API entirely.

Orders cannot be placed by value. The API works in quantities: you specify how many shares to buy or sell, and the fill cost is determined by the price at execution time. Value-based order placement is possible through the Trading 212 app and web platform but is not currently available through the API. This matters for portfolio tools that think in terms of target monetary exposure: they need to convert a target value into a share quantity before placing the order.

CFD positions cannot be accessed, managed, or even read. The API's scope is equity-only. There is no permission or endpoint path that changes this.

How Acubic uses the API

Acubic's Trading 212 integration uses a subset of this surface: account summary, positions, market orders, and historical order data. The integration reads live positions on a scheduled cycle, computes what needs to change to reach the target weights of the connected strategy, places market orders for the differences, and records every fill and rejection against the rebalance run. The full execution history is readable in the connection's audit log after the fact.

One structural difference from the eToro integration is worth naming clearly. A Trading 212 API key connection allows unattended rebalancing directly on a main Invest account. eToro's architecture requires a separate Agent Portfolio, a ring-fenced sub-account funded independently, before unattended execution is available. There is no equivalent constraint on the Trading 212 API, so all three automation modes are available on a main account from the outset. The eToro connection article explains the architecture behind that difference for anyone who holds both broker accounts. The automation modes article covers the full spectrum from monitoring-only through to full-auto and why the choice of broker changes what is available.

What this means if you are building

The Trading 212 Public API provides enough surface to run a complete, auditable portfolio rebalancing workflow. An application can read account state and open positions, compute the order set needed to reach a target allocation, place those orders, handle individual failures without aborting the run, and maintain a full historical record across cycles. For a rebalancing use case specifically, the market order rate limit of fifty per minute means a large portfolio can be serviced in a single run without pacing concerns. The combination of limit and stop order types extends the execution surface well beyond what a pure market-order API could support.

The limits worth designing around are the quantity-only order model, the primary-currency-only reporting, the fifty-pending-orders ceiling per ticker, and the beta status of the API. Beta means the surface is still changing: endpoints have been deprecated since launch and new capabilities continue to be added. Any integration should treat the official spec as the authoritative reference rather than relying on observed behaviour from a specific API version.

If you want to see the connection from the user's side rather than the API side, the Trading 212 connection guide covers what a connected account can see, what happens on a rebalance day, and what it will never do. When you are ready to connect, the Trading 212 integration page has the setup walkthrough and the full key permission list. If you have not built a portfolio strategy yet, how Acubic works covers the build side from the beginning.