Skip to content

REST API

Overview

The platform REST API is used for request-response client operations.

It covers the main client workflows:

  • authentication and session validation
  • trading operations
  • market and watchlist data
  • scripts and settings
  • price alerts and alert logs

Use REST when the client needs:

  • an explicit action with a deterministic response
  • current state snapshots
  • CRUD operations over user resources

For real-time updates such as quotes, balance changes, trade updates, and price alert triggers, use the WebSocket stream.

Base URL

https://{broker_domain}

Concrete endpoints are described in the sections below.

OpenAPI Specification

The REST API OpenAPI document is available as a static JSON file:

Download swagger.json

Authorization

Most private endpoints require a JWT token:

Authorization: <JWT_TOKEN>

The token is obtained during sign-in and is then used for subsequent authenticated requests.

For client endpoints, the server usually derives the current login from the JWT session instead of trusting a login passed in the request body.

Request Format

Content Type

Unless stated otherwise, requests use:

Content-Type: application/json

HTTP Methods

The client REST API uses the following methods:

  • GET for reading resources
  • PUT for creating or replacing resources in the current API design
  • POST for update-style operations
  • DELETE for deletions

Response Format

Most successful responses use one of two shapes.

structure + rows

This is the standard tabular response format used by many endpoints.

{
  "structure": ["id", "symbol", "price"],
  "rows": [
    [101, "EURUSD", 1.1000]
  ]
}

Simple status response

Some endpoints return a compact status payload.

{
  "data": "OK"
}

Error Format

Typical error response:

{
  "error": "INVALID_DATA",
  "message": "Validation failed"
}

Notes:

  • error is a short machine-readable code
  • message is a human-readable explanation when available
  • some endpoints may return only error for simple validation failures

Common HTTP Status Codes

A separate quick reference is available here: HTTP Status Codes.

Code Meaning
200 Request completed successfully
400 Validation error or bad request
401 Authentication failed or missing authorization
403 Authenticated but not allowed to access the resource
404 Resource not found
500 Internal server error
503 A v2 license runtime lease is unavailable for this session or operation

License v2 readiness

When a license selects runtime protocol v2, the Main Server requires an active license lease before creating new authenticated sessions or admitting risk-increasing trade operations. If the lease is absent or expires, affected requests return HTTP 503:

{
  "error": "LICENSE_NOT_ACTIVE",
  "message": "An active license lease is required for this operation"
}

This gate covers sign-in/token actions and market/pending order opens and modifications. Existing close and partial-close requests and cancellation operations remain available with their normal authorization and account checks. See License Runtime Protocol v2 for the full affected action list and migration behavior. The response does not mean that accepted trade requests or the trading service are otherwise healthy.

API Sections

Auth

Authentication and session management:

  • sign in
  • sign up
  • session check
  • password update

Trading

Trading operations for the current user:

  • open trade
  • close trade
  • cancel pending trade
  • modify trade
  • get open trades
  • get trade history

Market

Read market and watchlist data:

  • market info
  • asset info
  • short list
  • market watch list
  • add/delete market watch item

Scripts

User script management:

  • get scripts
  • add script
  • update script
  • delete script

Settings

User configuration endpoints.

Price Alerts

Price alert management and trigger history:

  • get alerts
  • create alert
  • update alert
  • delete alert
  • get alert logs
  • delete one alert log
  • delete all alert logs

Prop Trading

Prop challenge endpoints:

  • get active prop programs
  • start a prop challenge purchase
  • get current customer prop purchases and challenges

State Model

A common integration pattern is:

  1. use REST to authenticate and load the initial state
  2. use REST for user actions and configuration changes
  3. use WebSocket for real-time incremental updates
  4. periodically reconcile with REST if a strict fresh snapshot is required

Idempotency Notes

Not every endpoint is idempotent.

  • GET is read-only
  • DELETE usually removes a resource if it exists
  • PUT and POST semantics follow the current server design and are documented per endpoint

Always rely on the endpoint-specific documentation when exact behavior matters.

Versioning

This REST section documents the current client API behavior implemented by the platform. If endpoint behavior changes, the endpoint-specific page is the source of truth.