Skip to main content
Both Minerva and AsyncMinerva self-throttle to whatever your plan allows. You don’t have to write a token bucket, a semaphore, or back-off logic.

How it works

On the first call (sync or async), the SDK GETs /v2/usage/limits to discover your per-second rate, burst, and daily quota. The response is cached in-process and used to build a shared token bucket:
(Any field set to null is treated as “no limit on this axis.”) Subsequent calls — including concurrent ones under one client — pass through the bucket. When the bucket is empty, the call waits the minimal time needed to acquire a token.

When it helps

Most when you fan out concurrent requests:
…or use the built-in enrich_many / resolve_many which already share the same client + bucket.

Inspecting the active policy

Or for the sync client:

Opting out

Useful when:
  • You’ve already built your own throttler at the application layer.
  • You’re running tests against a recorded response.
  • You want to deliberately push toward 429 to learn your ceiling.

Older servers / endpoint not deployed

If /v2/usage/limits returns 404 (or any error), the SDK silently falls back to “no throttle” and continues normally. Your calls won’t fail because the limits probe didn’t work.