A technical overview of using Capital.com Public API with demo endpoints, sessions, tokens, rate limits and defensive bot design.
In plain English
This guide treats the broker as an external API with its own authentication, symbols, limits and failure states. A successful HTTP request is not always the same as a confirmed final action.
Start with the demo base URL
Capital.com's current public documentation lists separate live and demo base URLs and uses /api/v1 endpoints. Build the endpoint choice into configuration so live cannot be selected accidentally.
CAPITAL_ENV=demo
CAPITAL_DEMO_BASE=https://demo-api-capital.backend-capital.com
CAPITAL_LIVE_BASE=https://api-capital.backend-capital.comSessions are state
The documentation states that a session is launched with POST /api/v1/session. Authenticated requests use session tokens such as CST and X-SECURITY-TOKEN. The docs also currently state that a REST session is active for ten minutes and that the session-creation endpoint is limited to one request per second per API key.
Use a connectivity check
A health routine can distinguish “process is alive” from “broker API is reachable”. Capital.com documents a time endpoint that does not require authentication and a ping endpoint that uses session tokens.
Before placing any order
- Confirm environment is demo while developing.
- Confirm the market identifier maps to the intended instrument.
- Fetch current positions and enforce your own maximum exposure.
- Validate size against your configured limits.
- Check spread/price conditions if they are part of the strategy.
- Store an event ID before retrying uncertain submissions.
- Parse the broker's final confirmation rather than assuming HTTP success means trade success.
Official reference
Before you rely on this in production
- Demo/live environments are clearly separated.
- Authentication renewal is handled.
- Position/order state is checked before retrying.
- Rate limits and final confirmations are logged.