Skip to main content
Use the sandbox to build an API client without an account or key. It returns fixed sample data at https://0xinsider.com/sandbox and does not place orders or store your writes. If you want to inspect real data first, the public pick ledger is available without a credential.

Make a sandbox request

Append a documented API path to the sandbox base URL. Responses follow the operation’s documented fields and envelope, and include X-Oxi-Sandbox: true. The examples use 7 synthetic wallets and markets. Wallet addresses start with 0x51ab, markets have names such as “Sandbox Rovers”, and the data is fixed; do not treat its grades, prices, or P&L as real observations.

What works in the sandbox

The sandbox is the second server in the OpenAPI specification. It exercises response parsing, request shapes, pagination, and error handling; it does not establish production freshness, latency, or trading performance.

Read more than one page

A request with limit=3 can return:
Send cursor=sbx_3 to get rows 4 through 6, then cursor=sbx_6 for the final row. Stop when has_more becomes false; the last page omits next_cursor or uses null where the operation permits it. Event replay always keeps a cursor. Its final populated page returns sbx_7, and that cursor returns an empty page with the same cursor and completeness caught_up. An unknown cursor, or one beyond the collection, returns 400 with reason cursor_expired. Supported grade filters can reduce the collection, so not every filtered list contains all 7 rows.

Check invalid requests

The sandbox validates queries and JSON bodies against OpenAPI: Successful reads include X-Effective-Query for parameters the sandbox actually applies. Other documented filters can be validated without reproducing production filtering.
The sandbox rejects numeric values outside the schema’s bounds. Live list endpoints clamp whole-number limit values into range, so limit=0 can fail here while the live API uses limit=1.

Simulate an error

Add sandbox_status to request an error documented for that operation:
For example, a simulated 429 or 503 includes Retry-After: 60 and error.retry_at. Use these responses to exercise your error handling before going live.

Use an optional sandbox key

Most clients can call the sandbox with no credential. If your framework requires one, request a sandbox key:
The 201 response includes an oxi_sk_test_ key, the sandbox base URL, and links for obtaining live access. Sandbox keys do not change the returned data and cannot be listed or revoked. Production refuses a sandbox key with 401 invalid_api_key and reason sandbox_api_key. A live key also does not make the sandbox return live data.

Inspect the public ledger

This request returns production ledger data without a key:
A sealed entry contains a commitment hash and timestamps, with its side and price hidden. An opened entry reveals the payload and nonce after settlement, so you can verify that they match the commitment. The ledger returns all entries without pagination. 0xinsider/picks mirrors it and includes a verifier; the ledger reference explains the commitment fields and verification limits.

Limits

The sandbox has no production event stream, persistent writes, or real trading data. A sandbox key never grants access to authenticated production endpoints.

Switch to live data

  1. Subscribe to Pro or Max on Pricing.
  2. Generate a live key on Developers.
  3. Change the base URL to https://api.0xinsider.com and send Authorization: Bearer <key>.
The documented envelopes and field types stay the same. Cursor values and data change; start live pagination from the first page.

Continue building

Continue with the quickstart for common reads or authentication to choose scopes and manage keys.