> ## 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.

# Test and production environments

> Two environments with the same calls: simulated orders in test, real orders in production.

<Warning>
  **Availability, as of 2026-10-19: test environment available on request; production trading switched off.**

  | Environment | Status |
  | - | - |
  | Test (`/api/trading/test/v1`) | **Available on request.** Ask the Bullionwale desk to turn on API access for your account and issue a test key. Test orders are simulated and nothing is booked. |
  | Production (`/api/trading/v1`) | **Switched off.** Implemented, but production orders are refused (`403 production_trading_disabled`). Bullionwale will enable it per account once it opens; it is not available today. |

  `https://api.bullionwale.com` serves the API. Without a valid key, every call answers `401`. Your Bullionwale relationship manager will tell you when production trading opens.
</Warning>

The API has two environments. They offer the same five calls with the same request bodies, so code written against test works against production after you change the base path and the key.

| | Test | Production |
| - | - | - |
| Base path | `/api/trading/test/v1` | `/api/trading/v1` |
| Key | `bwk_test.…` | `bwk_live.…` |
| Orders | Simulated. Nothing is booked and nothing reaches the Bullionwale desk. | **Real.** Booked exactly like an order you place in the app. |
| Needs | API access for your account and a test key | Everything in [Production access requirements](/production-access) |

Once the API is available, both are served from `https://api.bullionwale.com`.

## What is the same

* **The checks on an order.** A test order goes through the same symbol, side, price-freshness, trading-halt, quantity and weight-allocation checks as a production order, and is priced the same way, with your own pricing. So a test order that is refused tells you a production order would be refused for the same reason, with one exception: `limit_exceeded` is judged against your **test** position (see [below](#how-test-orders-use-your-weight-allocation)), so it does not predict a production refusal, and a production order can be refused for your real position when a test order is not.
* **Authentication, scopes and idempotency.** Keys, scopes, `Idempotency-Key`, replays and `422 idempotency_key_reused` behave the same.
* **The error format.** Every refusal has the same shape and codes. See [Errors](/errors).

## What is different

| | Test | Production |
| - | - | - |
| Order identifier | `deal_label` (`T-<n>`) | `deal_no` (Bullionwale's deal number) |
| Order `status` | Always `filled` | `pending`, `open`, `closing`, `closed`, `rejected` or `deleted` |
| First answer to `POST /orders` | `201` | `201`, `202`, `409 order_rejected`, or one of the `503 booking_…` answers after a failure (see [Idempotency](/idempotency#outcomes-after-a-failure)) |
| Extra order fields | none | `status_detail`, `source`, `close_price`, `realized_pnl`, `closed_at` |
| `GET /orders` | Only your test orders | Your orders from every channel (app, web and API), with a `status` filter |
| `GET /positions` | Your test book | Your real book, plus a per-symbol `symbols` list |
| Stock and hedge | Not involved | A buy can be refused for stock (`out_of_stock`); an order can wait for hedge confirmation (`pending`) |
| Production switches | Not involved | Must be on (see [Production access requirements](/production-access)) |
| Order rate limits | Per key | Per key and per account |

## How test orders use your weight allocation

Test orders are checked against your account's **real** weight allocation, but against the net position of your **test** orders, not your real one. They never change your real position, and real orders never change your test position. `GET /positions` on the test path shows the test book.

## Moving from test to production

1. Run your integration against the test environment, including retries after timeouts and the error cases you handle.
2. Meet the [production access requirements](/production-access) and receive a live key.
3. Change the base path from `/api/trading/test/v1` to `/api/trading/v1` and use the live key.
4. Handle the production-only answers: `202` with a `pending` order, `409 order_rejected`, and the `503 booking_…` codes.
5. Check `GET /me`: `production_trading_available` must be `true` before you send a real order.


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