> ## Documentation Index
> Fetch the complete documentation index at: https://docs.scripxhq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# API reference overview

> Conventions shared by every ScripX API endpoint: one REST API across selling, buying, the cross desk, group netting and platform integration, with the base URL, X-ScripX-Key authentication, paise and bps units, cursor pagination, idempotency, rate-limit headers and error handling.

One REST API covers the whole ScripX product: selling scrips, covering customs duty with them, block deals on the cross desk, multi-entity netting, and everything a platform needs to run all of it for its own clients. Requests and responses are JSON over HTTPS, authenticated with an API key. The machine-readable contract is public at `GET /v1/openapi.json`.

Every domain term used on these pages is defined in the [Terminology annexure](/annexure/terminology).

## Base URLs

<CodeGroup>
  ```bash Production theme={"dark"}
  https://api.scripxhq.com
  ```

  ```bash Sandbox theme={"dark"}
  https://api.scripxhq.com   # same host, scripx_test_… key
  ```
</CodeGroup>

The environment lives in the key prefix, not the host. See [Environments](/environments).

## Authentication

Every endpoint requires the key header alongside a JSON content type:

```bash theme={"dark"}
X-ScripX-Key: <YOUR_API_KEY>
Content-Type: application/json
```

Keys carry scopes; each endpoint demands one. Scopes, plans and the auth error table are in [Authentication](/authentication).

## Units

All money is **integer paise** (`_paise` fields), all prices are **bps of face value** (`_bps` fields), all timestamps ISO 8601 IST. Worked examples: [Money and price](/annexure/money-and-price).

## Responses

Successful responses return the resource JSON directly, no envelope. Errors are a flat, opaque body with a stable slug to branch on:

```json theme={"dark"}
{
  "error": "request_error",
  "code": "unprocessable",
  "message": "amount_paise must be a positive integer"
}
```

Read `code ?? error` for the stable slug and switch on that plus the HTTP status, never on `message`. Every response, success or error, also carries an `X-Request-ID` header, the correlation id to log and quote in support. The full contract is on the [Errors](/errors) page.

## Pagination

Larger collections use cursor pagination: `limit` (default 100, maximum 500) and `cursor` (the `next_cursor` from a prior response). Responses add `count`, `total`, `next_cursor` and `has_more` alongside the data. The envelope is additive; non-paged reads of the same endpoints are unchanged.

## Idempotency

`POST /v1/orders` honours an `Idempotency-Key` header: re-sending the same key returns the original order instead of creating a duplicate. Use one key per logical order and retry fearlessly.

## Versioning and change policy

The `/v1` contract evolves **additively**: new endpoints, new optional fields, new webhook events. Build a tolerant reader and your integration never breaks:

1. Ignore JSON fields you do not recognise; never fail on an unknown key.
2. Ignore webhook events you have not subscribed logic to; acknowledge and move on.
3. Treat enums as open sets: handle known values, default the rest.

A breaking change ships as a new version with notice through these docs and by email, never silently inside `/v1`.

## Rate limiting

Every response carries `X-RateLimit-*` headers, and a 429 adds `Retry-After`. The header table and back-off guidance are in [Rate limits](/rate-limits).

## Need help?

<Card title="Write to support" icon="envelope" href="mailto:amin@eximfiles.io">
  Include your key prefix (never the full key) and the response body you received.
</Card>