# Sessions and tokens: how each API keeps you signed in

Independent and unofficial. Not affiliated with or endorsed by any broker or platform named here. Educational only: nothing here is advice, and nothing here recommends a broker or a trade.

This is the markdown version of https://openbrokerapi.com/guides/sessions-and-tokens, written from the same records as that page.

Risk warning: CFDs and spread bets are complex instruments and come with a high risk of losing money rapidly due to leverage. You can lose money on these products, and each provider publishes its own loss figure under FCA rules. You should consider whether you understand how they work and whether you can afford to take the high risk of losing your money. Automated and API trading can amplify losses through bugs, connectivity failures and runaway orders.

How each recorded broker API keeps you signed in: a login call that returns session tokens, a long lived key sent on every request, or an OAuth token that has to be refreshed. Taken from this site's authentication claims and session endpoint records, in order of name. Where a lifetime is not in the records the step says not recorded here.

- Checked: 2026-10-12
- For: Beginners whose first call worked and whose second call, an hour later, did not

## Steps

### 1. Capital.com: a session that lasts 10 idle minutes

You log in with POST /api/v1/session, sending the X-CAP-API-KEY header with your login identifier and the password you set for the key. The reply carries two tokens in its headers, CST and X-SECURITY-TOKEN, and both go on every later request. Capital.com says the session stays active for 10 minutes and that a longer silence produces an error on the next request. GET /api/v1/ping keeps it alive, and DELETE /api/v1/session ends it. The login call itself is limited to 1 request a second per API key, so log in once and reuse the tokens.

Status: verified. Source: [open-api.capital.com](https://open-api.capital.com/), checked 2026-10-12.

### 2. Deriv: a bearer token, and an application ID with a personal token

There is no login call in the recorded REST endpoints. You send a bearer token on each request, obtained either through an OAuth 2.0 app or as a Personal Access Token that the user generates and enters by hand. With a Personal Access Token, REST requests also need the Deriv-App-ID header, and leaving it out returns 401. Deriv describes OAuth 2.0 access tokens as short lived and gives no figure on the page opened, so token lifetimes are not recorded here. For trading, the recorded call POST /trading/v1/options/accounts/{accountId}/otp exchanges the token for a one time WebSocket address.

Status: verified. Source: [developers.deriv.com](https://developers.deriv.com/docs/intro/authentication/), checked 2026-10-12.

### 3. eToro: keys on every request, no session

No session endpoint is recorded for eToro. Each request carries three headers: x-api-key, which identifies the application, x-user-key, which identifies your user account, and x-request-id, a new unique identifier for every request. A user key belongs to one environment, Demo or Real, chosen when the key is made, and eToro says to create two keys if you need both. An expiry date can be set on a key when it is generated. No default lifetime is given on the page opened, so it is not recorded here. The authentication claim in this site's eToro record also notes an OAuth 2.0 bearer token as an alternative to the two key headers.

Status: verified. Source: [api-portal.etoro.com](https://api-portal.etoro.com/core/getting-started/authentication.md), checked 2026-10-12.

### 4. IBKR: a gateway login that needs a regular ping

Read in a browser on 12 October 2026. Retail users of the Web API log in through the Client Portal Gateway in a browser on the same machine. IBKR's Web API v1.0 pages give POST /iserver/auth/status to ask whether the brokerage session is authenticated, POST /tickle to stop the session timing out, which IBKR expects about every 60 seconds, and POST /logout to end it, after which any further activity needs a new login.

Status: verified. Source: [interactivebrokers.com](https://www.interactivebrokers.com/docs/web-api/v1/endpoints/session/ping-the-server), checked 2026-10-12.

### 5. IG: two session tokens, or OAuth tokens at version 3

POST /session at VERSION 2 takes your API key in the X-IG-API-KEY header with a username and password, and returns CST and X-SECURITY-TOKEN in the reply headers. Both go on every later call. IG's REST trading API guide says the two tokens are valid for 6 hours at first and are extended up to a maximum of 72 hours while in use. This site's IG record marks the lifetime as conflicting, because it also holds a reading of 12 hours between calls from IG Labs' FAQ, so write code that logs in again on a refusal instead of trusting either clock. At VERSION 3 the login returns OAuth tokens: the guide gives 60 seconds as an example lifetime for the access token and says the refresh token also expires some time later. The recorded call POST /session/refresh-token exchanges a refresh token for a new pair.

Status: verified. Source: [labs.ig.com](https://labs.ig.com/rest-trading-api-guide.html), checked 2026-10-12.

### 6. OANDA: one personal token, no session

No session endpoint is recorded for OANDA. You generate a personal access token in the Account Management Portal on fxTrade, under Manage API Access in My Services, after agreeing to the API licence. Every recorded OANDA endpoint then lists the Authorization header as required, carrying that token as a bearer token, and there is nothing to keep alive between calls. Whether and when the token expires is not on the page opened and is not recorded here.

Status: verified. Source: [developer.oanda.com](https://developer.oanda.com/rest-live-v20/introduction/), checked 2026-10-12.

### 7. Saxo: OAuth, with refresh tokens that replace each other

Saxo signs you in with OAuth 2.0 and its endpoint records list a bearer Authorization header on each call. For learning, the developer portal issues an access token for the simulation environment that is valid for 24 hours, so a first script needs no login flow. A real application uses an authorisation code flow and then refresh tokens. Saxo says that every time a refresh token is used you receive a new one, which replaces and invalidates the one before, so save the new token each time or the next refresh fails. The lifetime of an ordinary access token is not on the page opened and is not recorded here.

Status: verified. Source: [developer.saxo](https://www.developer.saxo/openapi/learn/security), checked 2026-10-12.

### 8. Trading 212: a Basic header, no session

No session endpoint is recorded for Trading 212. The API key and secret are joined with a colon, encoded in Base64 and sent as Authorization: Basic on every request. Nothing is exchanged for a token and nothing needs refreshing. The paper trading host and the live host take the same header format, so the host you call is what decides which account answers. Whether a key expires is not recorded here.

Status: verified. Source: [docs.trading212.com](https://docs.trading212.com/api), checked 2026-10-12.

## Sources

- Status: verified. Source: [Capital.com Public API](https://open-api.capital.com/), checked 2026-10-12.
- Status: verified. Source: [Deriv API: authentication](https://developers.deriv.com/docs/intro/authentication/), checked 2026-10-12.
- Status: verified. Source: [eToro API portal: authentication](https://api-portal.etoro.com/core/getting-started/authentication.md), checked 2026-10-12.
- Status: verified. Source: [IBKR Web API v1.0 documentation, ping the server](https://www.interactivebrokers.com/docs/web-api/v1/endpoints/session/ping-the-server), checked 2026-10-12.
- Status: verified. Source: [IG Labs REST trading API guide](https://labs.ig.com/rest-trading-api-guide.html), checked 2026-10-12.
- Status: verified. Source: [OANDA v20: introduction](https://developer.oanda.com/rest-live-v20/introduction/), checked 2026-10-12.
- Status: verified. Source: [Saxo OpenAPI: security](https://www.developer.saxo/openapi/learn/security), checked 2026-10-12.
- Status: verified. Source: [Trading 212 API docs: authentication](https://docs.trading212.com/api), checked 2026-10-12.
- Status: verified. Source: [IBKR Web API v1.0 documentation, authentication status](https://www.interactivebrokers.com/docs/web-api/v1/endpoints/session/authentication-status), checked 2026-10-12.
- Status: verified. Source: [IBKR Web API v1.0 documentation, logout of the current session](https://www.interactivebrokers.com/docs/web-api/v1/endpoints/session/logout-of-the-current-session), checked 2026-10-12.
- Status: verified. Source: [IBKR Web API documentation, limitations of the Client Portal Gateway](https://www.interactivebrokers.com/docs/web-api/authentication/cpgw/limitations-of-the-client-portal-gateway), checked 2026-10-12.

## Related pages

- [Getting started with API trading](https://openbrokerapi.com/guides/getting-started-with-api-trading): What an API is, what you need and how to make a first call safely.
- [All guides](https://openbrokerapi.com/guides): Step by step guides, each step with the page it was read on.
- [Brokers](https://openbrokerapi.com/brokers): The record for each broker: access, limits, endpoints and error codes.
- [Platform APIs](https://openbrokerapi.com/platforms): APIs that belong to trading software offered by many brokers.
- [Error codes](https://openbrokerapi.com/errors): What each error means, and the fix where the source gives one.
- [Compare two APIs](https://openbrokerapi.com/compare): The same fields from two records, side by side.
- [Learn to code](https://openbrokerapi.com/learn): A learning track from a first script to a demo account call.

## Licence and how to cite

The records behind this page are all rights reserved. This file is the page itself, at its own address, in another format. It is not part of the CC BY 4.0 downloads listed at https://openbrokerapi.com/data. Quote from it with a link to the page.

Cite as: Sessions and tokens: how each API keeps you signed in. Broker API Hub, https://openbrokerapi.com/guides/sessions-and-tokens, newest check 2026-10-12.

Where you rely on a single figure, cite the source and the checked date printed beside it as well. Where this page and a broker's own documentation differ, the documentation wins.
