Skip to main content
Version: 1.0.2
Download OpenAPI YAML

Exness Trader API

Clean domain model:

  • Order = trading instruction
  • Position = open exposure
  • Operational and Trading history via Trading
  • Realtime updates via Server Events
  • Static and semi-static settings via Configuration

General API rules:

Authorization:

  • The primary Public Trader API authentication method is request signing with a public API key.
  • Signed requests use the EXN-* headers documented in the security schemes.
  • EXN-DATA contains a base64url-encoded JSON payload with the fields that are signed.
  • EXN-SIGN contains the Ed25519 signature of the decoded EXN-DATA payload.
  • EXN-DATA and EXN-SIGN must use base64url without = padding.
  • EXN-SIGN-VERSION must be 1.
  • The signed payload must contain:
    • api_key: same value as EXN-API-KEY
    • idempotency_key: same value as EXN-IDEMPOTENCY-KEY; empty string for signed GET requests
    • timestamp: Unix time in milliseconds, same value as EXN-TIMESTAMP
    • sign_version: same value as EXN-SIGN-VERSION
    • method: uppercase HTTP method, for example POST
    • path: request path with query string exactly as sent by the client
    • body_hash: SHA-256 hash of the request body, base64url-encoded without padding
  • EXN-SIGN signs the decoded EXN-DATA payload bytes, not the base64url string.
  • For requests without a body, body_hash is the SHA-256 hash of the empty string, base64url-encoded without padding.
  • Query strings must be signed exactly as transmitted. Clients must not reorder or re-encode query parameters after signing.
  • Duplicate query parameters are rejected.
  • The timestamp must be close to the server time. Clients should generate a fresh signature for every request.
  • The API key must be allowed to access the requested account, source IP, and operation scope.
  • Authentication headers are modeled as OpenAPI security schemes, not as ordinary operation parameters. This keeps generated clients and Swagger UI from showing duplicate credential inputs.
  • Authentication errors use the public error model. Clients should use error.code and error_message as the stable contract and must not rely on internal diagnostic text.

Signed POST example:

POST /v1/trading/accounts/123456789/orders HTTP/1.1
EXN-API-KEY: exnsk-live-example
EXN-IDEMPOTENCY-KEY: order-20260316-0001
EXN-TIMESTAMP: 1773656070123
EXN-SIGN-VERSION: 1
EXN-DATA: <base64url_encoded_payload>
EXN-SIGN: <base64url_encoded_signature>
Content-Type: application/json

Decoded EXN-DATA payload for the signed POST:

{
  "api_key": "exnsk-live-example",
  "idempotency_key": "order-20260316-0001",
  "timestamp": 1773656070123,
  "sign_version": 1,
  "method": "POST",
  "path": "/v1/trading/accounts/123456789/orders",
  "body_hash": "47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU"
}

Signed GET example:

GET /v1/configuration/accounts/123456789/account HTTP/1.1
EXN-API-KEY: exnsk-live-example
EXN-IDEMPOTENCY-KEY:
EXN-TIMESTAMP: 1773656070123
EXN-SIGN-VERSION: 1
EXN-DATA: <base64url_encoded_payload>
EXN-SIGN: <base64url_encoded_signature>

Decoded EXN-DATA payload for the signed GET:

{
  "api_key": "exnsk-live-example",
  "idempotency_key": "",
  "timestamp": 1773656070123,
  "sign_version": 1,
  "method": "GET",
  "path": "/v1/configuration/accounts/123456789/account",
  "body_hash": "47DEQpj8HBSa-_TImW-5JCeuQeRkm5NMpJWZG3hSuFU"
}

Date and time:

  • all date-time values are returned in UTC
  • ISO 8601 format with explicit offset is used, for example: 2026-03-16T12:54:30+00:00

Pagination:

  • cursor is an opaque continuation token
  • cursor must not be parsed or modified by the client
  • when cursor is used, it cannot be combined with filters except limit, unless explicitly stated otherwise

Sorting:

  • historical collections are returned in ascending chronological order, from older to newer, unless explicitly stated otherwise

Monetary values and numeric precision:

  • account monetary values are represented as decimal strings, expressed in the account currency, and rounded according to the decimal precision of that currency
  • examples with 2 decimal places assume an account currency that uses 2 decimal places
  • trading volumes are represented as decimal strings to avoid precision loss
  • trading request/entity price fields are represented as decimal strings to avoid precision loss
  • market data prices, including tick bid/ask and candle OHLC values, are represented as JSON numbers and modeled in OpenAPI as type: number, format: double
  • volume and instrument price precision are instrument-specific and must not be inferred from account currency precision

Idempotency:

  • mutating trading methods require an idempotency key
  • signed requests use EXN-IDEMPOTENCY-KEY
  • for signed GET requests, EXN-IDEMPOTENCY-KEY must be present with an empty value, and the signed idempotency_key field must be an empty string
  • clients should use the same idempotency key when safely retrying the same request
  • if the same idempotency key is reused for the same account, operation kind, and request payload, the duplicate request is accepted with the original operation_id and is not executed again
  • if the same idempotency key is reused for the same account and operation kind with a different request payload, the request is rejected as a duplicate key conflict
  • idempotency records are retained for a limited time; after the retention period expires, the same key may be treated as a new request
  • when an idempotency key is provided, it is echoed back as client_request_id in the ACK response, in the corresponding transaction_event, and in the operation status response; this allows correlating events with originating requests without storing the operation_id mapping
  • idempotency key length must be 5..128 characters
  • allowed characters are A-Z, a-z, 0-9, ., _, -, ~

Async trading operations:

  • mutating trading methods return ACK with operation_id
  • final execution result is delivered through Server Events and can be read from operation status
  • clients should use operation_id or client_request_id to correlate REST requests with operation and transaction events
  • REST errors before ACK are limited to synchronous request, authentication, authorization, account lookup, rate limit, and service availability failures
  • trading-rule and execution failures after ACK are represented by public error_code and error_message fields in transaction_event and operation status payloads
  • operation-level x-public-error-codes lists synchronous REST error codes
  • operation-level x-public-async-error-codes lists final asynchronous trading result codes

Current state vs history:

  • current trading state is available through Trading Snapshot and Server Events
  • historical closed orders and deals are available through Trading History
  • open orders and open positions are not returned by Trading History

Authentication​

Public API key identifier used by signed requests.

This value must match the api_key field inside the signed EXN-DATA payload. Unknown, expired, or mismatched API keys are returned as AUTH_INVALID_API_KEY.

Security Scheme Type:

apiKey

Header parameter name:

EXN-API-KEY