REST API Reference
Base URL: https://api.reya.xyz/v2 — see Environments for all endpoints.
Download the current mainnet contract: REST OpenAPI spec. This download describes the API currently available at that endpoint, which may differ from the version described in this guide. For the API 3.6.2 contract documented here, use the immutable canonical spec source. When generating a client from the live spec, configure its base URL as https://api.reya.xyz/v2 (or https://api-devnet.reya-cronos.network/v2 for devnet1); the spec uses a relative server URL.
Overview
The Reya DEX REST API v2 provides programmatic access to the Reya Perpetual Exchange, enabling traders to interact with the platform algorithmically. This API is designed for developers and traders who want to build automated trading systems, integrate with existing platforms, or develop custom interfaces for the Reya DEX ecosystem.
Key Features
Market Data: Access comprehensive market information, including asset definitions, market summaries, asset oracle prices, and order-book depth
Order Management: Create, modify, cancel, and monitor orders with support for various order types (limit, trigger)
Position Tracking: Monitor your current positions and historical executions
Wallet Integration: Manage wallet configurations and access wallet-specific data
Price Data: Access asset oracle prices through
/assetOraclePricesand historical market data through candle endpoints. The legacy/pricesendpoints are removed; use market summaries/depth for market prices.
API Structure
The API is organized into several logical sections:
Reference Data: Discover markets and assets definitions, trading fees
Market Data: Access real-time and historical market data, including asset oracle prices, candles, market summaries, depth, and order execution
Wallet Data: Get information about the wallet's accounts, positions and orders
Order Entry: Create, modify, and cancel orders
Both perpetual and spot endpoints are covered by the same reference; where an endpoint is product-specific (for example perpExecutions vs spotExecutions), the path makes it explicit.
Order history
GET /v2/wallet/{address}/orderHistory is an account-history endpoint for recent matching-engine order updates across the wallet's accounts. It is meant for account-history UI, support tooling, and other low-volume lookups. It returns the newest records first, capped at 100 records per request, and accepts optional startTime and endTime query parameters as millisecond timestamps. Order records use the public Order shape. On orderHistory rows, sequenceNumber is present as the matching-engine order-event sequence. firstFillId and fillCount are optional and appear when the update includes a fill range. triggered is always omitted on history rows: armed-versus-fired state is unknown here. Use openOrders or live orderChanges for that distinction.
The time filters are inclusive. When paging backward, passing the previous page's meta.endTime as the next endTime can repeat boundary rows. De-dup that overlap by Order.sequenceNumber when you need to preserve all rows that share the same millisecond timestamp. Clients that do not need same-ms boundary ties may instead page with endTime = meta.endTime - 1.
Retention and recording eligibility
History retains the latest 2,000 order-change records per account. One order can produce several records; this is not a limit of 2,000 distinct orders. The following recording rules apply:
Automatic exclusion: more than 100 order-change events per account in a fixed minute of matching-engine event time excludes the account from further recording, starting with event 101. Counts are per account across its markets, not aggregated across the wallet. These are event counts, not API requests or a rolling requests-per-minute limit.
Automatic resumption: recording resumes prospectively after two consecutive completed minutes with fewer than 50 events each. Minutes with no activity count toward that period. Skipped events are not backfilled.
Explicit exclusions: accounts configured as excluded do not receive new history records, regardless of activity. The automatic resumption rule does not override an explicit exclusion.
Restart behavior: automatic activity classification resets when the history service restarts; explicitly configured exclusions still apply. Previously skipped events remain missing.
Exclusion affects history recording only: trading and live orderChanges continue. Existing retained rows can still be returned, so an old or empty history response is not evidence that no orders were placed. The response has no recording-eligibility or completeness indicator.
If your application needs a complete order timeline, persist the orderChanges stream in your own storage and handle disconnections and gaps explicitly. REST history can supplement that record only where rows are available; it cannot guarantee recovery of missed events. Reconcile current orders and settled executions separately—an open-orders snapshot does not reconstruct every intermediate order update.
Signatures
Order-management requests require wallet signatures. Read-only market and wallet queries do not require a signature. See Signatures & Nonces.
For real-time data needs, consider using our WebSocket Info API for streaming updates. To place and cancel orders over a persistent connection, see the WebSocket Order Entry API.
The full endpoint reference — every path, request body, and response schema — is rendered from the OpenAPI specification under this section.
Transport failures and retrying
See Handling ambiguous outcomes for the API 3.6.2 error codes and when to retry or reconcile. An unanswered request may have been applied.
Rate limits
See Rate Limits for the agreed allowances and recovery guidance. Account-operation rejections use HTTP 400 with an error code and optional retryAfterMs; IP limits can return HTTP 429. REST trading operations, including cancellations and countdown refreshes, share the per-IP trading bucket.
Last updated