Thanks to visit codestin.com
Credit goes to docs.context.dev

Skip to main content
Context.dev applies fixed one-minute request windows. Your current plan limit is visible in the dashboard and on the pricing page. Read the response headers at runtime instead of copying a plan table into application code.

Read the current window

Authenticated API responses expose these headers when a per-minute limit applies: Log these values as numbers, not strings, and attach them to the operation name. Slow producers or queue work before Remaining reaches zero.
Endpoint price and rate-limit usage are separate. A zero-credit operation can still use request-rate capacity, and a single operation can represent more work than another. Do not infer one from the other.

Recognize a 429

When the current window is exhausted, the API returns 429 with a stable error category:
The response also includes:
Retry-After contains the number of seconds until the window resets, from 1 to 60. A rate-limited request consumes no API credits.

Retry with a limit

Honor Retry-After, add jitter to avoid a synchronized retry burst, and stop after a small number of attempts.
Before wrapping an SDK call, inspect the installed SDK’s retry behavior. Some generated clients retry selected statuses by default. Disable one layer or account for the combined attempt count so retries do not multiply.

Reduce request volume

Use these controls in order:
  1. Skip duplicate calls. Cache successful results in your server or database according to the product’s freshness requirement.
  2. Deduplicate concurrent work. Coalesce requests for the same normalized input into one in-flight promise or job.
  3. Bound fan-out. Use a worker queue with explicit concurrency for bulk work.
  4. Use batches for asynchronous volume. Batch management has a separate admission and polling bucket; processed items still consume their operation credits.
  5. Degrade intentionally. Return an editable form, text fallback, cached record, or queued state when enrichment is optional.
Do not keep an unbounded retry queue inside a user request. A 429 that outlives the user’s latency budget should become a product fallback or background job.

Weighted endpoints

Most synchronous API calls consume one unit from the one-minute request window. Operations marked with a Rate limit weight badge consume that many units per call. For example, synchronous Crawl and the beta multi-product extraction operation currently have a weight of 10. Rate-limit weight is not the same as credit cost. Read both badges on the operation’s API-reference page and use the returned rate-limit headers to pace real traffic.

Separate limits

  • Monitor management and history operations use their own organization-level request bucket. The scrape work performed by scheduled runs is governed by monitor limits and billing, not by the number of list or retrieve calls.
  • Batch submit, list, retrieve, result, cancel, and delete operations use a separate management bucket. The pages processed by a batch still settle against work credits.
  • Prefetch costs zero API credits but still uses the ordinary authenticated API rate limit.
  • Logo Link image delivery has a separate quota and service path from the core API.
Use the headers returned by the specific surface you are calling. Do not reuse a core API limit value to pace monitor or batch management requests.

Batch API has its own bucket

Batch management calls use a 1,000-unit-per-minute organization bucket. Submission consumes 50 units; list, retrieve, results, cancel, and delete calls consume 1 unit. These calls cost zero API credits, while the pages processed by the job are reserved and settled separately. See Submit Batch Jobs for the complete accounting model.

Avoid polling bursts

For an asynchronous operation:
  • Prefer a webhook when the surface offers one.
  • Otherwise, start with a slow poll interval and increase it after repeated pending responses.
  • Add jitter when many jobs are started together.
  • Stop polling on terminal success or failure.
  • Cap total elapsed time and preserve the job ID for later recovery.

Test the fallback

Before launch, simulate a 429 response and confirm:
  • The code reads Retry-After case-insensitively.
  • The total attempt count is bounded across SDK and application layers.
  • The user sees an intentional fallback after the final attempt.
  • The request is not treated as a credit charge.
  • Logs contain status and rate metadata, not the API key or scraped content.

Next steps

Production checklist

Set timeouts, retries, and fallbacks for production traffic.

Prefetch brand data

Start eligible retrieval work before a user needs the result.

Troubleshooting

Distinguish rate limits from credit, input, and service errors.