Rate limits

Limits are per API key, per minute, on a sliding window.

Environment	Default
Sandbox	10,000 requests/minute
Production	1,000 requests/minute

Sandbox is higher on purpose — see Environments.

Every response includes the current state:

x-ratelimit-limit: 1000
x-ratelimit-remaining: 847
x-ratelimit-reset: 1735689660

Exceeding it returns 429 with Retry-After in seconds.

Staying within the limit

Use webhooks instead of polling. A poll loop is the most common cause of exhausting a limit, and it is almost always replaceable with an event.

Raise limit rather than making more calls. One request for 100 records costs one unit, not 100.

Spread scheduled work. If a nightly job starts exactly on the hour, it competes with every other integration doing the same. Add a random offset.

Use a separate key per workload. Limits are per key, so a batch import cannot starve your interactive traffic if they use different keys.

Handling 429

The SDK retries automatically, honours Retry-After, and applies jitter so a fleet of clients does not retry in lockstep and recreate the spike:

const client = new MineTech({
  apiKey,
  maxRetries: 3,
  onRetry: ({ attempt, delayMs }) => log.warn(`retry ${attempt} in ${delayMs}ms`),
});

If you handle it yourself, honour Retry-After and add jitter. A fixed-interval retry from many workers is indistinguishable from the original overload.

Need a higher limit? Email engineering@minetech.rw with your key prefix and expected volume.