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

# Scope reference

> Every scope an API key can carry, which calls each one unlocks, and which a new key gets by default.

A key carries scopes that decide which calls it may make. Bullionwale sets them when it issues the key; ask for the ones your integration needs (see [Getting access](/getting-access)).

| Scope | Default | What it allows | Calls today |
| - | - | - | - |
| `account:read` | Yes | Read your account profile, API status, trading limits and API keys. | `GET /me`, `GET /limits`, `GET /keys` |
| `rates:read` | Yes | Read live rates, symbols and market status. | `GET /rates`, `GET /rates/{symbol_code}`, `GET /symbols`, `GET /symbols/{symbol_code}`, `GET /market/status` |
| `orders:read` | Yes | Read your own orders, limit orders, positions, realized P\&L and delivery requests. | `GET /orders`, `GET /orders/{order_id}`, `GET /limit-orders`, `GET /limit-orders/{limit_order_id}`, `GET /positions`, `GET /pnl`, `GET /pnl/daily`, `GET /deliveries`, `GET /deliveries/{delivery_id}` |
| `orders:write` | No | Place orders, and place, edit and cancel limit orders. | `POST /orders`, `POST /limit-orders`, `PATCH /limit-orders/{limit_order_id}`, `DELETE /limit-orders/{limit_order_id}` |
| `webhooks:read` | No | Read own webhook subscriptions. | `GET /webhooks`, `GET /webhooks/{webhook_id}` |
| `webhooks:write` | No | Create, change, test and delete own webhook subscriptions. | `POST /webhooks`, `PATCH /webhooks/{webhook_id}`, `DELETE /webhooks/{webhook_id}`, `POST /webhooks/{webhook_id}/test`, `POST /webhooks/{webhook_id}/rotate-secret` |

"Default" means a new key gets the scope unless you ask otherwise. `orders:write` is granted only when you ask for it. On a live key it is not enough on its own: a production order also needs production trading enabled for your account and on for the platform (see [Production access requirements](/production-access)); without that it is refused with `403 production_trading_disabled` even though the key has the scope.

The same scopes apply in both environments: a test key and a live key with the same scopes may make the same calls, each on its own base path.

## How scopes are checked

* Every call needs exactly one scope, shown above and on each endpoint's page in the [API reference](/api-reference/overview).
* A call whose scope the key lacks is refused with `403 insufficient_scope`. Nothing else happens: an order refused for its scope is not booked.
* Scopes do not combine into anything larger. A key with `orders:write` but not `orders:read` can place an order but cannot read it back, so a trading key normally carries both.
* `GET /me` returns the key's `scopes`, so a program can check them at start-up instead of failing on its first order.

```json 403 Forbidden theme={null}
{
  "detail": {
    "code": "insufficient_scope",
    "message": "This API key does not have the 'orders:write' permission."
  }
}
```

## Choosing scopes

| Integration | Scopes |
| - | - |
| Dashboard or reconciliation job | `account:read`, `orders:read` |
| Order bot | `account:read`, `orders:read`, `orders:write` |

Give each system the smallest set it needs, on its own key, so a leaked read-only key can never place an order.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.