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
| Network | Arc Testnet Live |
|---|---|
| REST | https://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 forPOST,PUTandDELETE /api-key. - Market names: perpetuals are
ASSET-PERP(for exampleBTC-PERP). Spot markets areBASE-QUOTE(for exampleBTC-USDC).GET /marketslists 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 /timeand trade/order history), milliseconds (for examplenext_funding_time) or Unix seconds (candles,GET /markets/{id}/trades). Each endpoint's reference entry says which. - Pagination:
/positions,/open-orders,/trade-history,/order-historyand/position-historyreturn apaginationobject withnext_cursor/prev_cursor. Pass one back ascursor, withdirection=nextorprev. For these thelimitrange is 1–1000, default 50. Other list endpoints document their own limits (for example/transaction-historyuseslimit+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 }
| Status | Meaning |
|---|---|
| 400 | Invalid parameters. Paginated history endpoints report Validation failed: … |
| 401 | The endpoint needs a valid API key and secret (see Authentication) |
| 403 | Invite-only deployment and your account is not allowed, or an address in the path that is not your API key's account |
| 409 | Invite code already used (invite-only deployments) |
| 404 | Unknown route, instrument or order |
| 429 | Rate 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 |
| 410 | The endpoint was removed (GET /auth) |
| 500 | Upstream 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 |
| 501 | Not supported by the exchange (for example POST /account/update-margin) |
| 503 | Temporarily 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
/depositsor/withdrawalsroutes. - 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.