Skip to main content

Developer overview

Base URL, conventions and error format of the <BrandName short /> API.

RealTime Exchange exposes a REST API and a Socket.IO real-time API. The app itself uses both. This section documents the endpoints that return real data and are safe for integrators. The API is read-only for trading: use it for market data, your account's state and notifications. Orders are placed and cancelled from the app (on-chain or through the gasless relayer); no public endpoint places or cancels an order. It is generated from the backend's actual route table: check:api fails the docs build if a documented route disappears.

Base URL​

NetworkArc Testnet Live
RESThttps://arc-testnet-api.realtime.exchange
WebSocket (Socket.IO)wss://arc-testnet-api.realtime.exchange path /socket.io

The hosted API serves routes at the root (for example GET /markets). A self-hosted backend mounts the same routes under its API_PREFIX setting instead. The code default for that setting is /api/v1. GET /health, GET /ready and GET /version are always served at the root.

Conventions​

  • Requests: query parameters for GET, JSON bodies for POST, PUT and DELETE /api-key.
  • Market names: perpetuals are ASSET-PERP (for example BTC-PERP). Spot markets are BASE-QUOTE (for example BTC-USDC). GET /markets lists the markets this network serves.
  • Numbers: prices and sizes are usually decimal strings, so parse them with a decimal library, not floating point. The exception is GET /orderbook, which returns raw on-chain integers (see its reference entry).
  • Timestamps differ by endpoint: nanoseconds as strings (for example GET /time and trade/order history), milliseconds (for example next_funding_time) or Unix seconds (candles, GET /markets/{id}/trades). Each endpoint's reference entry says which.
  • Pagination: /positions, /open-orders, /trade-history, /order-history and /position-history return a pagination object with next_cursor / prev_cursor. Pass one back as cursor, with direction=next or prev. For these the limit range is 1–1000, default 50. Other list endpoints document their own limits (for example /transaction-history uses limit + offset).

Errors​

Errors use HTTP status codes with this JSON body:

{ "success": false, "error": "Authentication required. Provide valid API-KEY and API-SECRET headers", "timestamp": 1790000000000 }

An unknown route returns 404 with an extra message field:

{ "success": false, "error": "Not Found", "message": "Cannot GET /nope", "timestamp": 1790000000000 }
StatusMeaning
400Invalid parameters. Paginated history endpoints report Validation failed: …
401The endpoint needs a valid API key and secret (see Authentication)
403Invite-only deployment and your account is not allowed, or an address in the path that is not your API key's account
409Invite code already used (invite-only deployments)
404Unknown route, instrument or order
429Rate limited. REST routes share a limit of 1000 requests per minute by default, counted per API-KEY header value when you send one, otherwise per IP. Each IP also has an overall ceiling of 5× that limit across all keys. /health, /ready and Socket.IO are not limited. A 429 from the main limit carries RateLimit-* and Retry-After headers; one from the IP ceiling does not. POST /faucet/auto also allows only 10 requests per minute
410The endpoint was removed (GET /auth)
500Upstream failure (indexer, chain or a dependent service). A browser request from an origin the deployment does not allow, or a request body that is not valid JSON, also ends as a 500
501Not supported by the exchange (for example POST /account/update-margin)
503Temporarily unavailable, for example Account key update in progress; retry from POST /register or DELETE /api-key. Retry with backoff

The TradingView datafeed endpoint follows the UDF convention and reports errors inside an HTTP 200 body ({"s":"error"}). An unknown symbol returns {"s":"no_data"}, and an unsupported resolution is a 400.

What is not in this reference​

Some routes exist in the backend but are left out on purpose:

  • Placeholders: vaults, lending writes, settlement history, analytics and similar routes return constant or empty data.
  • App-internal and service routes: health proxies, webhooks, and proxies to separate services such as the leaderboard, referrals and TP/SL executor, whose schemas those services own.
  • Deposits and withdrawals: make these on-chain from the app. Don't use the backend's /deposits or /withdrawals routes.
  • Trading: perpetual orders are signed in your browser and submitted on-chain or through the gasless relayer. There is no REST endpoint that places a perpetual order for you.