The eToro API: What It Can and Cannot Do

If you are building automation against an eToro account, or want to understand what a connected application can actually do on your behalf, the eToro public API is the right place to start. Its capabilities are genuinely useful for systematic portfolio management. Its limits are equally real, and some are enforced at the API level rather than left as policy choices for application developers to configure around. This article covers both, drawn from Acubic's experience as a listed eToro App Store integration operating under an approved OAuth client.

What the API can read

eToro exposes a public API to applications registered in its App Store. Authenticated connections can retrieve the following from a connected account:

• Live portfolio positions, with each position's instrument, units held, open rate, current market value, net profit, and a field that identifies whether the position was opened directly or through a copy relationship with another trader.
• Pending orders: orders submitted to eToro that have not yet filled, typically because the underlying market was closed at placement time.
• Instrument data, including symbol resolution and current rates. The API supports lookups for resolving numeric instrument identifiers to their ticker symbols.
• Account snapshot data, covering total invested capital, available balance, and PnL.

Read endpoints operate under a shared rate limit of 60 requests per 60 seconds. That budget is pooled across related portfolio and account endpoints together, not allocated independently per endpoint. For most rebalancing workflows the ceiling is not binding, but an integration that fetches positions, PnL, and instrument data on every cycle should account for the shared budget rather than treating each endpoint as if it had the full 60 available.

What the API can execute

On the write side, the API supports the following execution operations for managing portfolio positions:

• Open a new long position for a given instrument, by dollar amount or by units.
• Close an existing position, referenced by its specific position identifier. The API requires the positionId of the open position; you cannot issue a generic sell instruction for an instrument and expect all holdings in it to close.
• Cancel a pending order that has not yet filled.

All execution endpoints share a tighter rate limit than reads: 20 requests per 60 seconds. This is a shared quota across every execution endpoint, not a separate allowance per endpoint type. A portfolio rebalance across ten to twenty positions sits comfortably within that ceiling. A larger position count, or an integration that submits and immediately polls in rapid succession, needs to structure the rebalance to respect the shared limit.

Order submission is asynchronous. A successful acceptance response from an execution endpoint means the order was received for processing, not that it was filled. Confirming execution requires a separate lookup call against the order's returned identifier. Individual order rejections are reported at the order level with the broker's stated error code and reason, so a rebalance that encounters a rejected order for one position continues independently for the rest. The execution record shows what succeeded and what did not across every run.

What the API cannot do

Several things fall entirely outside the API's scope. Being explicit about them prevents building against assumptions that do not hold.

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 eToro account regardless of what the application instructs. Withdrawals and deposits happen through eToro's own interface, outside the API.

Copy-traded positions are not directly manageable through a rebalancing workflow. When an eToro user copies another trader, those positions carry a reference that identifies the copy relationship. The API returns them in portfolio reads, but treating them as ordinary managed holdings creates conflicting signals: the copy relationship governs them, not the account holder acting independently. Acubic excludes them by design, reading the copy reference on each position and skipping any that carry one. A rebalance never touches copied positions.

Account credentials do not pass through the API. Under the OAuth flow, authentication happens on eToro's own login page. eToro issues a scoped access token, which is what the connected application holds. The user's password never reaches a third-party application at any stage. Stored credentials are encrypted at rest and never returned to the browser or written to logs.

Standard account connections do not support unattended execution. This is the most significant operational constraint for automation use cases, and it has its own section below.

Authentication paths

The eToro API supports two authentication methods for third-party integrations, each carrying a different capability profile.

OAuth PKCE is the standard path for App Store integrations. The user is directed to eToro's login page, authorises the connection, and eToro issues a scoped bearer token. The token can be revoked from inside eToro at any time, with no action needed from the application. Acubic uses this path for standard account connections.

API keys use two values: an x-api-key and an x-user-key, generated from eToro's API Key Management settings. This path does not require an OAuth redirect and is the basis for both direct API integrations and for connections to an eToro mirrored account. Keys are rotated by generating new pairs in eToro's settings rather than expiring automatically.

Standard account versus the eToro mirrored account

The most important operational distinction the API creates is between a standard connection and a connection to an eToro mirrored account, because they determine the automation ceiling available to a connected application.

A standard connection requires a per-rebalance approval. The application prepares an order set, and nothing is sent to eToro until the account holder confirms it. This is a structural property of standard account connections, not a setting an application can configure away. It applies whether the connection uses OAuth or API keys. Acubic surfaces this as the one-click mode: each scheduled rebalance generates a pending approval, the user reviews the proposed trades, and execution begins only after confirmation.

Between one-click and full automation there is a third option: monitoring. In monitoring mode the application reads live positions, tracks drift from the target allocation, and reports on performance without placing any orders. Observing what a rules-based strategy would do without committing to execution is a legitimate long-term use case, not only a trial step.

The eToro mirrored account is a ring-fenced sub-account funded separately from the main balance. Trades execute within the mirrored account and are sized proportionally: if you fund the mirrored account with a given investment amount relative to its virtual balance, each position is scaled to that proportion. A mirrored account connection supports execution without a per-order prompt, because the sub-account is isolated: trades on it do not affect the main account's positions, and the token issued for it does not carry access to main-account data. Capital moves between the main account and the mirrored account only through eToro's own funding interface, not through the API. Acubic calls this the full-auto mode, and it is available only on mirrored account connections.

One structural rule applies to both connection types: each broker connection is bound to a single strategy. Two strategies cannot both issue orders against the same account simultaneously.

The result is a clear capability map. A standard account connection yields one-click approval or monitoring, but not unattended execution. A mirrored account connection can add full-auto to that set. An application cannot bypass the approval gate on a standard account regardless of how it is configured, and no setting inside Acubic changes that rule.

Demo and real environments

eToro maintains a demo environment alongside the live trading environment. Connections to the demo environment read from paper accounts and place simulated orders; no real capital is affected. The two environments are completely separate and require distinct credentials. A token or key pair from the demo environment cannot authenticate against the real one.

For testing an integration before connecting a live account, the demo environment provides the same API surface against safe paper data. The same rate limits govern reads and execution calls, and the approval behaviour on standard demo connections is present in demo as well.

What this means in practice

The eToro API provides enough surface to run a complete, auditable portfolio rebalancing loop. An application can read live positions, compute the orders needed to reach a target allocation, place those orders, handle individual failures with the broker's stated reasons, and maintain a full execution record across rebalances. That is the workflow Acubic runs for every connected account on every scheduled cycle.

The limits that shape what can be built are the per-rebalance approval gate on standard accounts, the 20-request-per-minute shared ceiling on execution endpoints, and the exclusion of copy-traded positions from direct management. Within those limits, the API supports systematic, repeatable portfolio maintenance without requiring anything beyond what eToro makes available to registered App Store integrations.

For a walkthrough of how the connection works from the user's side, including what Acubic can see, what happens on a rebalance day, and what it never does, see how Acubic works with eToro. The one-click versus full-auto comparison explains the automation modes in more depth and why your broker changes which ones are available. For a step-by-step guide to setting up automation, how to automate an eToro portfolio covers the full setup process. And for the portfolio construction side, what data Acubic uses explains how the strategy is built before any connection is made.

When you are ready to connect an eToro account, the eToro integration page has the setup walkthrough and the full description of each connection mode. If you have not built a strategy yet, the AI portfolio builder is where to start.