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
A429 response includes a Retry-After header (in seconds):
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 returning429.
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
- Use batch endpoints for bulk operations. One batch request uses one concurrency slot regardless of item count.
- Use
output: "url"instead ofoutput: "base64"— URL mode frees the rendering slot as soon as the file is written to storage. - Set reasonable timeouts. A stuck page (waiting for a broken asset) holds a slot. Use
resource_timeoutto cap it.
Size limits
Exceeding size limits returns
413:
Timeout limits
Pass
timeout in the request to override the default (up to the maximum):