Skip to main content

Credit model

PDFBase uses a simple credit-based billing model:
  • 1 credit = 1 output PDF (or image, or extraction result).
  • Failed requests = 0 credits. You only pay for successful outputs.
  • Batch of N items = N credits. A batch request that produces 50 PDFs costs 50 credits.
Specific rate limits and pricing tiers will be finalized at launch. The mechanics below (headers, concurrency, size limits) are stable.

Rate limit headers

Every response includes headers showing your current usage:

When you hit a limit

A 429 response includes a Retry-After header (in seconds):
Ignoring Retry-After and hammering the API will result in progressively longer cooldowns. Respect the header.

Concurrency limits

PDF rendering is resource-intensive. Your plan has a cap on how many PDFs can be rendered simultaneously. If all slots are occupied, new requests queue for up to 30 seconds before returning 429. This is separate from the per-minute rate limit. You can be within your request limit but at your concurrency cap.

How to stay under concurrency limits

  1. Use batch endpoints for bulk operations. One batch request uses one concurrency slot regardless of item count.
  2. Use output: "url" instead of output: "base64" — URL mode frees the rendering slot as soon as the file is written to storage.
  3. Set reasonable timeouts. A stuck page (waiting for a broken asset) holds a slot. Use resource_timeout to cap it.

Size limits

Exceeding size limits returns 413:

Timeout limits

Pass timeout in the request to override the default (up to the maximum):