Too many reveals in a short window

The burst cap, why it exists, and the pattern that avoids it.

Reveals have a hard per-minute burst cap on top of the normal rate limits:

Too many reveals in a short window. This cap protects the dataset and resets each minute.

The response includes reset_seconds and a Retry-After header, and the cap resets every minute on its own.

Why it exists

Reveal is the one call that turns a redacted record into contact data. A cap on how fast that can happen is what keeps the dataset from being walked record by record. It is not aimed at you, and it is not a per-day allowance being consumed: it resets in under sixty seconds.

The pattern that avoids it

  1. Export instead of looping reveals. Same price per contact, one job, verified output. If your agent is revealing more than a handful of rows, it should be creating an export.
  2. Add jitter, not a tight retry. Exponential backoff with randomness spreads a burst across the window instead of re-colliding with it.
  3. Chunk the work. Reveal what you need for the next step, act on it, then continue.

Instructions in your agent's system prompt make this automatic. A line like 'for more than 20 contacts, create an export rather than revealing individually' turns the limit into a non-event.

Nothing is lost when you hit it. Reveals that succeeded are permanent, the credits behind them are spent normally, and the failed call charged nothing.

Still stuck? support@argorant.com