Skip to main content
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). “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); 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.
  • 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.
403 Forbidden

​
Choosing scopes

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