Environments
| Sandbox | Production | |
|---|---|---|
| Key prefix | mt_test_ | mt_live_ |
| Base URL | https://sandbox.api.minetech.rw | https://api.minetech.rw |
| Data | Isolated | Real operational records |
| Request signing | Off by default | On by default |
| Rate limit | 10,000/min | 1,000/min |
| Webhook URLs | http and localhost allowed | https, publicly routable only |
The SDK picks the base URL from the key prefix, so a test key cannot reach production data even if the URL is wrong.
Why sandbox has the higher rate limit
Integration work is bursty — you replay fixtures, run test suites, and hammer endpoints while learning the shape of the API. Throttling that costs you time and protects nothing, because sandbox data is disposable. Production is the opposite: steady traffic against real records, where a runaway loop is worth stopping.
Environment-scoped resources
Keys, webhook endpoints and IP allowlist entries all belong to exactly one environment. A sandbox event will never reach a production endpoint, and a live event will never reach a sandbox one — the two are separated at the point of delivery, not merely by convention.
Every webhook payload also carries environment, so a shared receiver can branch:
if (event.environment === 'test') return handleFixture(event);
Signing during onboarding
Test keys default to unsigned so you can get a first call working without also debugging HMAC. Turn signing on for the test key before you go live — it is a per-key toggle, and finding a signing bug in sandbox is much cheaper than finding it in production.