Why does the ceiling exist at all?

Every forward writes and reads through a row-level-security ledger twice: the key and target on the way out, the response, byte counts and the balance on the way back. That is what makes revocation take effect on the very next request, keeps private and cloud-metadata addresses unreachable, and settles every trip exactly. The transfer is never traced or archived — target, headers, body and response go the moment it completes. A relay that skipped the ledger writes could go faster, but it could not promise any of that — so the burst budget is published at 600 forwards a minute and refusals are free.

Are rate-limited requests charged?

No. The request never reaches the upstream, no connection is opened, so no trips are deducted.

Can the limit be raised?

The published ceiling is 600 forwards per rolling minute per key, with a ten-second cooldown past it, plus a wider per-account ceiling so one key cannot starve the others. It is architecture rather than a sales gate: the relay is database-bound because each call is ledgered on both legs. Use separate keys per environment or workload to spread the budget. Nothing from a completed trip is traced, logged or stored — it is purged as soon as the roundtrip ends.

429 · rate_limited

rate_limited: you are sending forwards too quickly

rate_limited means the rolling-minute allowance for the key or the account is used up. The request was not forwarded, no upstream connection was opened and no trips were charged. The ceiling exists because every forward is authorised and recorded through a row-level-security database on both legs — the key and the target on the uptrip, the response, byte counts and the balance on the downtrip. That ledger is what makes revocation effective on the next request and keeps private and metadata addresses unreachable, so the bound is published rather than discovered. Nothing else about the trip is retained: no trace log, no archived copy — it is purged the moment the roundtrip completes.

Common causes

A tight retry loop sending forwards as fast as they fail.
Many parallel workers sharing a single key.
A burst backfill with no pacing between batches.

How to fix it

01Treat rate_limited as backpressure: wait the retry_after_seconds it returns (10), then resume — retrying inside the cooldown only earns another refusal.
02Spread work across several keys or reduce concurrency so bursts stay under the limit.
03Batch jobs should pace themselves rather than saturating the allowance at the start of a run.

What it looks like

rate_limited

async function forward(payload, attempt = 0) {
  const res = await fetch('https://backfireapi.base44.app/functions/forward', {
    method: 'POST',
    headers: { Authorization: `Bearer ${key}`, 'Content-Type': 'application/json' },
    body: JSON.stringify(payload),
  });
  const envelope = await res.json();

  if (!envelope.ok && envelope.error.code === 'rate_limited' && attempt < 5) {
    await new Promise((r) => setTimeout(r, 2 ** attempt * 1000));
    return forward(payload, attempt + 1);
  }
  return envelope;
}

Every error code

blocked_target insufficient_trips invalid_key rate_limited upstream_timeout payload_too_large response_too_large dns_failure account_frozen

Questions about this

Try it with 5,000 free trips.

No card, no subscription, and the balance never expires.

Create an account Read the docs