The eToro API: What It Can and Cannot Do

Key takeaways

• The eToro public API can read positions, pending orders, instrument data and account balances, and can open positions, close them by position ID and cancel pending orders.
• eToro's API does list money transfers between a customer's own eToro accounts, but Acubic never calls them and never withdraws, deposits or sends money out of your eToro account.
• Reads are limited to 60 requests per minute and trading calls to 20 per minute, tracked per user key.
• When you create an API key you choose one environment (Demo or Real) and a permission level: Read for portfolio data, Write to execute trades.
• On a standard account, Acubic needs your one-click approval for each rebalance; unattended execution is available only on an eToro sub-account.

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. eToro's documentation states that limits are tracked per user key over a 1-minute rolling window, and that exceeding them returns a 429 Too Many Requests status code, so integrations should retry with exponential backoff (eToro API rate limits). 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, the limit eToro's documentation lists for opening, closing and cancelling orders in both Real and Demo environments (eToro API rate limits). 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.

Money movement is where the API and Acubic differ. eToro's API reference does include transfer functions, for example an endpoint that "Executes an internal transfer from the source account to the destination account for the authenticated customer" (eToro API reference: internal account-to-account transfer), and a separate endpoint for moving money into a trading sub-account. Acubic uses none of them. It reads positions and places, closes and cancels equity orders; it never withdraws, deposits or transfers cash, and bank deposits and withdrawals happen in eToro's own interface. The one funding step Acubic can perform is the one you ask for: when you create an eToro sub-account through Acubic, eToro funds it with the investment amount you choose from your main eToro balance, and that money stays inside your eToro account.

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 sub-account. Keys are rotated by generating new pairs in eToro's settings; a key does not expire on its own unless you set an expiration date when you create it.

How to create an eToro API key

eToro's developer documentation describes the steps for generating your own user key (eToro API authentication):

1. Log in to eToro, open Settings from the sidebar and select Trading.
2. In the API Key Management section, click Create New Key.
3. Name the key, choose the environment (Demo or Real) and choose the permission level. Optionally add an IP whitelist or an expiration date.
4. Confirm with the verification code eToro sends to your phone.
5. Copy the new key from the Generated Keys list.

Two choices in that form matter most. First, the environment: "Each key can only be used for one environment", so testing on Demo and running on Real means two keys. Second, the permission level, which decides whether an application can trade at all:

Select “Read” if you only need to access your portfolio data. Select “Write” if you need to execute trades.

A read-only key is the safer choice for anything that only monitors or reports. Give an application a write key only if you want it to place orders, and revoke or rotate the key if you stop using the application.

Standard account versus the eToro sub-account

The most important operational distinction the API creates is between a standard connection and a connection to an eToro sub-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 its One-Click Approval mode: each scheduled rebalance generates a pending approval, the user reviews the proposed trades, and execution begins only after confirmation.

A connection also does not have to trade at all. Until you activate rebalancing, Acubic places no orders on a connected account. When you activate it, the app offers two modes: One-Click Approval and Full Automatic.

The eToro sub-account is a ring-fenced account inside eToro, funded separately from the main balance, where Acubic places the strategy's trades. Order sizes are scaled to the amount you funded it with, relative to the sub-account's virtual balance. An eToro sub-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. The sub-account is funded from your main eToro balance when it is created, with the amount you choose; Acubic does not move money between the two accounts after that. Acubic calls this Full Automatic mode, and on eToro it is available only on eToro sub-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.

Acubic modes by eToro connection type

Mode	Standard account connection	eToro sub-account connection
Connected, rebalancing not activated (no orders)	Available	Available
One-Click Approval (you approve each rebalance)	Available	Available
Full Automatic (no per-rebalance approval)	Not available	Available

The result is a clear capability map. A standard account connection yields One-Click Approval, but not unattended execution. An eToro sub-account connection can add Full Automatic. 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. If you also hold a Trading 212 account, see how the Trading 212 API compares.

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.

Sources

1. Rate Limits, eToro API Docs (accessed 12 October 2026).
2. Execute an internal account-to-account transfer, eToro API Docs (accessed 12 October 2026).
3. Authentication, eToro API Docs (accessed 12 October 2026).