Platform Essentials
The web terminal is a client of the same API you get
There is no privileged internal interface. Everything the terminal does, it does through the public API, which is the only reliable way to keep documentation honest.
api.reference
v1- GET/v1/instrumentsDefinitions and specifications
- GET/v1/accounts/{id}/balancesPer-currency balances
- POST/v1/ordersPlace an order
- DELETE/v1/orders/{id}Cancel a working order
- GET/v1/positionsOpen positions and margin
Two surfaces
Request-response for state, a stream for everything that moves
Splitting them this way is what keeps a busy integration from polling a price endpoint forty times a second.
REST
Accounts, balances, positions, order management, instrument definitions and history. You ask, the platform answers with the current state.
Idempotency keys on writes
Cursor pagination on history
Errors carry a machine-readable code
See it live
A request and response, not a promise in a document
Every endpoint on this page ships with a runnable example and its exact JSON response, the same reference your integrators will build against.
What you can rely on
Four commitments an integrator cares about
Everything else is documentation. These are the parts that decide whether an integration survives its second year.
Validation lives in the engine
Price bands, size caps, exposure limits and margin checks run server-side, so an integration cannot route around a limit your desk set.
Scoped keys, self-issued
Account holders create keys in the client area, choose a scope per key and revoke them at will. Issuance and revocation are both logged.
Published schemas
Every release ships machine-readable schemas and a changelog, so client generation stays a build step rather than a reading exercise.
Deliberate deprecation
When a version is superseded the previous one stays available for a stated period, which makes migration a plan rather than an incident.
Build against a full copy before a client ever touches it
The sandbox mirrors the production surface with virtual balances, including the error responses. Integrations that only ever saw the happy path are the ones that break on launch day.
Environment
sandboxBalances
virtualSurface
identical to productionError responses
reproducibleFAQ
Trading API: common questions
5 short answers to what teams ask before a demo.
Yes. There is no separate privileged interface. The web terminal and the mobile clients are consumers of the same public API, which is what keeps the documentation accurate.
No. Validation runs in the engine rather than the client, so price bands, size caps, exposure limits and margin checks apply identically regardless of where an order originated.
Account holders issue their own keys from the client area, choose the scope for each key and revoke them when needed. Every issuance and revocation is written to the account activity log.
Yes, a separate environment with virtual balances that mirrors the production API surface, including error responses, so integrations can be tested fully before going live.
The API is versioned, with schemas and a changelog published per release. When a version is superseded the previous one remains available for a stated period so integrators can migrate deliberately.
Still have a question?
A specialist will answer it directly, with your set-up in mind.
Ask a specialistPut your engineers in front of ours
We will go through the API surface, the streaming model and the sandbox with your technical team.