Sessions and tokens: how each API keeps you signed in
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.
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.
Steps
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.
open-api.capital.comchecked
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.
developers.deriv.comchecked
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.
api-portal.etoro.comchecked
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.
interactivebrokers.comchecked
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.
labs.ig.comchecked
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.
developer.oanda.comchecked
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.
developer.saxochecked
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.
docs.trading212.comchecked
Sources
- Capital.com Public APIchecked
- Deriv API: authenticationchecked
- eToro API portal: authenticationchecked
- IBKR Web API v1.0 documentation, ping the serverchecked
- IG Labs REST trading API guidechecked
- OANDA v20: introductionchecked
- Saxo OpenAPI: securitychecked
- Trading 212 API docs: authenticationchecked
- IBKR Web API v1.0 documentation, authentication statuschecked
- IBKR Web API v1.0 documentation, logout of the current sessionchecked
- IBKR Web API documentation, limitations of the Client Portal Gatewaychecked