Skip to main content
The eBRC API has a single base URL. There is no separate sandbox host:
Which mode a request runs in is decided by the key you send, not by the host you call. Going live is a credential change, not a URL change: swap the key, leave the base URL and every request untouched.
Generation endpoints work in both modes. In live mode, a generation request is typically acknowledged within about 2 hours.

​
How the mode is decided

  • The key prefix is authoritative. dev_ → test, prod_ → live. This is read from the x-api-key header on every request.
  • A request header can never change it. If a key is present, mode headers are ignored entirely, so nothing you send alongside a test key can make it act live.
  • Test and live data are isolated. Every exporter, remittance and generation request belongs to one mode. A test key presented against a live exporter is rejected with the same 403 as a key from another platform.
  • Every generation request records the mode it was filed in, so a test run is never mistaken for a live filing.

​
Working across both modes

Test and live keys are issued as a pair, so you can hold both at once (one in staging, one in production) and point them at the same base URL. Because the two modes are isolated, records do not carry over: exporters you created with a test key have to be created again with the live key before you can file for them.

​
Data extraction

Shipping bill extraction runs on the eBRC API, at the same base URL as everything else. It authenticates with your ordinary dev_/prod_ eBRC key. There is no separate extraction credential. The parse itself carries no mode: a shipping bill parses identically in test and live, no DGFT sandbox is involved and nothing is filed. The allowance, however, is split by key: a prod_ key spends the live budget and a dev_ key spends the test budget, and the two do not draw on each other. The figures are on the pricing page.