Skip to main content
Version: v1.0.5

True Markets CeFi REST

Overview​

This API allows clients to interact with the CeFi trading platform for order management, market data retrieval, and account information.

Base URLs​

EnvironmentBase URL
Productionhttps://api.truex.co/v1/cefi/
UAT (sandbox)https://api.uat.truex.co/v1/cefi/

UAT and Production require VPN / PrivateLink network access for institutional clients. Contact [email protected] for network onboarding.

The legacy /api/v1/ path prefix continues to accept requests for backwards compatibility, but is deprecated and will be removed on August 5, 2026 — the same sunset date as the v2024_01_01 schema version. New integrations should use /v1/cefi/.

Authentication​

Protected endpoints accept either of two authentication methods:

  • Institutional clients — HMAC-SHA256 signed requests using an API key (organization_id / key_id / secret).
  • Retail clients — a JWT bearer token in the Authorization header, with no per-request signing.

Market data and service-health endpoints are public and require no authentication.

Institutional: obtaining API-key credentials​

Direct CeFi REST/WS/FIX access for institutions requires KYB onboarding. Begin at https://www.truex.co/sign-up, or contact [email protected] for help. Approved organizations receive an organization_id, key_id, and HMAC secret.

Retail: JWT bearer token​

Retail clients authenticate directly by presenting a True Markets-issued JWT access token in the Authorization: Bearer <token> header — no per-request HMAC signing. Obtain a token pair by registering an ES256 (EC P-256) API key and exchanging a signed challenge via the Auth API (POST /v1/auth/api-key/token); the same token is also issued by the standard sign-in flows.

The access token must carry a client_id claim, which scopes every request to your CeFi client. That claim is present only once your account is onboarded to CeFi — a JWT without a client_id claim is rejected with 401 Unauthorized.

Signature computation (HMAC-SHA256)​

Each authenticated request must include the headers X-Truex-Organization-Id, X-Truex-Key-Id, X-Truex-Timestamp (UTC Unix seconds, within ±15s of server time), and X-Truex-Signature. Compute X-Truex-Signature as:

signature = base64( HMAC_SHA256( secret, METHOD + "\n" + PATH + "\n" + TIMESTAMP + "\n" + BODY ) )

where BODY is the exact serialized request body (empty string for GET/DELETE). See docs.truex.co for reference implementations in Python, Go, and shell.

API Versioning​

The API uses date-based versioning via the X-Truex-Version header. To request a specific API version, include the header in your request:

X-Truex-Version: v2024_01_01

Supported Versions:

VersionStatusDescription
v2024_01_01Deprecated (Default) — Sunset August 5, 2026Original API format - responses return raw data arrays/objects
v2026_01_23CurrentNew envelope format - responses wrapped in { "data": [...], "pagination": {...} }

If no version header is provided, the API defaults to v2024_01_01. Use the /v1/cefi/versions endpoint (or the legacy /api/v1/versions) to discover supported versions programmatically.

Response Format by Version:

  • v2024_01_01: [{...}, {...}] (raw array) or {...} (raw object)
  • v2026_01_23: { "data": [...], "pagination": { "size": 10, "next_cursor": "..." } }

Error Response Format by Version:

  • v2024_01_01: RFC 7807 Problem Details format
  • v2026_01_23: { "error": { ...RFC 7807 Problem Details... } }

Deprecation Policy: When a version is deprecated, responses will include RFC 8594 headers:

  • Deprecation: Date when the version was deprecated
  • Sunset: Date when the version will be removed

The legacy /api/v1/ path prefixes share the August 5, 2026 sunset date with the v2024_01_01 schema version. Migrate to /v1/cefi/ before that date.

Authentication​

Clients must compute and send an HMAC signature in x-truex-auth-signature.

Compute the payload exactly as:

timestamp + method + path + body

Then compute the signature as:

Base64( HMAC_SHA256(secret, payload) )

Rules:

  • timestamp is x-truex-auth-timestamp in seconds since Unix epoch.
  • timestamp must be no older than 15 seconds and no more than 1 second in the future.
  • method is uppercase HTTP method (GET, POST, DELETE, etc.).
  • path is everything after the domain, including leading / (e.g. /api/v1/order) and excludes query string parameters.
  • body is the exact raw request body string. Use an empty string for requests with no body.

Example payload:

  • 1700000000POST/api/v1/order{"client_id":"7","instrument_id":"1","qty":"1","price":"100"}

Example signature (shell):

  • printf '%s' "$PAYLOAD" | openssl dgst -sha256 -hmac "$SECRET" -binary | base64

Note, method is all upper case and path is everything after the domain name including the / (e.g. /api/v1/order). Required headers:

  • x-truex-auth-token: The ID of the HMAC key being used (API key).
  • x-truex-auth-signature: The signature generated from processing the payload with the HMAC key.
  • x-truex-auth-timestamp: Current time as seconds since epoch.
  • x-truex-auth-userid: Client identifier.

Security Scheme Type:

apiKey

Header parameter name:

x-truex-auth-token

Terms of Service

https://truex.co/tos