> For the complete documentation index, see [llms.txt](https://docs.reya.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.reya.xyz/developers/devnet/api-reference/rest-api-reference.md).

# REST API Reference

**Base URL (devnet1)**: `https://api-devnet.reya-cronos.network/v2` — see [Environments](/developers/devnet/getting-started/environments.md) for all endpoints.

**Download the current devnet1 contract:** [REST OpenAPI spec](https://api-devnet.reya-cronos.network/v2/openapi-spec.yaml). This endpoint serves the deployed API contract and may advance beyond the version described in this guide. For the exact API **3.5.2** contract, use the immutable [canonical spec source](https://github.com/Reya-Labs/reya-api-specs/tree/4fafae7d19076e8d31811930000a78d842758d9f). When generating a client from the live spec, configure its base URL as `https://api-devnet.reya-cronos.network/v2`; 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 `/assetOraclePrices` and historical market data through candle endpoints. The legacy `/prices` endpoints 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 were verified on devnet1 on September 11, 2026:

* **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`](/developers/devnet/api-reference/websocket-api-reference.md) 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](/developers/devnet/authentication/signatures-and-nonces.md).

For real-time data needs, consider using our [WebSocket Info API](/developers/devnet/api-reference/websocket-api-reference.md) for streaming updates. To place and cancel orders over a persistent connection, see the [WebSocket Order Entry API](/developers/devnet/api-reference/ws-exec-api-reference.md).

***

The full endpoint reference — every path, request body, and response schema — is rendered from the OpenAPI specification under this section.

{% hint style="info" %}
This reference is generated from OpenAPI; do not infer request rules from handwritten examples. GitBook imports the REST spec from the devnet1 endpoint linked above. Use the pinned canonical source when generating a client for API 3.5.2; use the live download to inspect the currently deployed contract. In 3.5.2, `timeInForce` is required for every create, including SL/TP. `reduceOnly` is required for every perp LIMIT IOC create (send `true` for a reducing order or `false` for an ordinary IOC). Spot, perp GTC/GTT, and trigger creates must omit the field entirely — even sending `false` on those request types is invalid.
{% endhint %}