PDFCrowd API Rate Limits: What Happens When You Send Too Many Conversion Requests?

PDFCrowd returns 429 when your conversion request frequency exceeds the allowance for your license. It returns 430 when too many conversions are running at the same time. For a 429, slow or pause new submissions; for a 430, let active conversions finish and reduce concurrency. The exact limits depend on your license, so check your current plan or account documentation for its allowances.

These errors describe different bottlenecks. A retry loop that keeps submitting requests can worsen either one. First identify whether the problem is request rate or simultaneous work, then adjust the matching part of your client.

429 versus 430: identify the limit you reached

Response	Meaning	PDFCrowd reason code	First response
HTTP 429	Request rate limit reached: too many conversion submissions within a timeframe. PDFCrowd’s FAQ describes the allowance in terms of requests per minute.	120	Pause or slow new submissions.
HTTP 430	Concurrent request limit reached: too many conversions are processing simultaneously.	121	Let in-flight conversions finish and reduce parallel work.

PDFCrowd defines a rate limit as the maximum number of conversions allowed per minute and concurrency as the number that can run at the same time. Both limits are license-dependent. The reviewed documentation does not establish one universal numeric threshold, an exact reset duration, or whether every limit response includes a retry header, so do not assume those values. See the official status code reference, rate limit FAQ, and plan parameter definitions.

Diagnose the response before changing your client

Record the HTTP status. Distinguish 429 from 430; they require different traffic changes.
Capture PDFCrowd’s reason code. Read x-pdfcrowd-reason-code when present. Code 120 points to the request-rate allowance; 121 points to concurrency.
Save the response body and headers. The HTTP API documentation recommends inspecting status, headers, and body. Append ?errfmt=json to the HTTP endpoint to request structured error details; plain text is the default.
Keep the job identifier. Record x-pdfcrowd-job-id when provided so the conversion can be located in logs or a support request.
Compare workload to your license. Check the current account or plan terms for both the per-minute allowance and simultaneous conversion allowance.

A 503 is a different condition: PDFCrowd describes it as a temporary network issue. Do not treat every transient server response as a rate limit, and do not retry invalid input, authentication failures, or account problems without correcting their cause.

Reduce request rate or concurrency

When the response is 429

Stop adding work briefly, then resume at a lower submission rate.
Space requests over time instead of releasing a large burst at once.
Use a bounded retry policy with increasing delays for temporary failures. Avoid an unbounded or immediate retry loop.
If 429s continue after traffic is paced, compare the sustained workload with the rate allowance for your license and consider whether a different plan is needed.

When the response is 430

Reduce the number of simultaneous conversion requests.
Wait for active conversions to finish before submitting more jobs.
Keep a bounded number of workers rather than starting a conversion for every queued item at once.
If the required parallel workload persistently exceeds the account allowance, review the license’s concurrency limit.

These controls are not interchangeable. A low concurrency cap can prevent 430s while still allowing a high request rate if jobs finish quickly; pacing requests can prevent 429s while still allowing too many long-running jobs to overlap. Track both submissions over time and active jobs.

Runnable client pattern: bounded workers and backoff

The following Python example shows the client-side control flow around a conversion request: cap simultaneous work, slow after 429, and reduce parallel work after 430. The endpoint and conversion parameters depend on the PDFCrowd API operation you use; this example leaves the conversion request itself in a small function for you to fill with your documented operation. It does not assume an exact limit or reset interval. Use the PDFCrowd API documentation for the endpoint, authentication, and conversion parameters for your account.

import random
import time
from concurrent.futures import ThreadPoolExecutor, as_completed

MAX_WORKERS = 2
MAX_ATTEMPTS = 5


def convert(item):
    """Call your documented PDFCrowd conversion operation for item."""
    raise NotImplementedError("Add the PDFCrowd conversion request here")


def submit_with_backoff(item):
    for attempt in range(MAX_ATTEMPTS):
        try:
            return convert(item)
        except Exception as exc:
            # Replace these checks with the status and reason code exposed
            # by the PDFCrowd client or HTTP response you use.
            status = getattr(exc, "status_code", None)
            reason = getattr(exc, "reason_code", None)

            if status == 429 or reason == 120:
                delay = min(2 ** attempt, 30) + random.uniform(0, 0.5)
                time.sleep(delay)
                continue

            if status == 430 or reason == 121:
                # Back off longer for a concurrency limit. A production
                # queue should also lower its active worker count.
                delay = min(2 ** (attempt + 1), 60) + random.uniform(0, 0.5)
                time.sleep(delay)
                continue

            # Do not retry unrelated errors blindly.
            raise

    raise RuntimeError(f"Conversion did not succeed after {MAX_ATTEMPTS} attempts")


items = ["input-1", "input-2", "input-3"]
with ThreadPoolExecutor(max_workers=MAX_WORKERS) as pool:
    futures = [pool.submit(submit_with_backoff, item) for item in items]
    for future in as_completed(futures):
        result = future.result()
        print(result)

This is a control-flow template, not a drop-in PDFCrowd API request: the supplied research does not specify a particular conversion endpoint’s request schema or a language SDK’s exception shape. Map the actual HTTP status, response body, and x-pdfcrowd-reason-code header from your client into the checks. For a production queue, make the worker limit configurable and reduce it after repeated 430s rather than merely sleeping every worker at the same time.

Operational notes: reliability, performance, and cost

Reliability

Retries should be bounded and should target temporary conditions. PDFCrowd recommends increasing delays for temporary failures, while invalid input, authentication, and account errors need correction before retrying. Preserve the original status, headers, response body, and job ID in logs. This makes it possible to distinguish a rate-limit response from a conversion or network failure.

Performance

More parallel requests do not always improve throughput: if they exceed concurrency, they produce 430 responses; if they arrive too quickly, they can produce 429 responses. Use a queue with separate controls for submission pacing and active workers. Tune those controls against the actual allowance and observed conversion completion times rather than guessing a universal number.

Cost and plan choice

PDFCrowd’s limits depend on the license. If a tuned workload repeatedly reaches a limit, identify which allowance is binding before changing plans: rate pressure calls for reviewing the per-minute allowance, while concurrency pressure calls for reviewing simultaneous conversions. PDFCrowd suggests considering an upgrade when customers consistently hit limits. The reviewed sources do not provide current numeric thresholds for each plan, so verify the account’s terms before estimating capacity.

Troubleshooting common limit errors

Symptom	Likely cause	What to do
HTTP 429, reason 120	Too many conversion submissions in the relevant timeframe.	Pause or pace new work; inspect the license’s request-rate allowance.
HTTP 430, reason 121	Too many conversions running at once.	Let active work finish and lower the worker/concurrency cap.
Limit error repeats immediately after retry	Retries are too frequent, unbounded, or synchronized across workers.	Bound retries, increase delays, add jitter, and pace queued submissions.
HTTP 503	PDFCrowd identifies this as a temporary network issue, separate from 429 rate limiting.	Use bounded retries with increasing delays; retain diagnostics.
Other client or API error	May be invalid input, authentication, account state, or another failure.	Inspect the response and fix the underlying issue before retrying.
Cause is unclear	Status alone may not provide enough diagnostic context.	Capture the body, `x-pdfcrowd-reason-code`, `x-pdfcrowd-job-id`, and relevant headers; consult current plan details.

Or skip the browser setup

If your task is to capture a page as an image or PDF rather than convert documents through PDFCrowd, ScreenshotNeo provides a website screenshot API. The one-call request below returns a screenshot; see the ScreenshotNeo API documentation for output and capture options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

ScreenshotNeo accepts cookie and consent banners like a visitor, then removes 60+ known consent platforms, newsletter popups, and chat widgets before the capture; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed, and the response identifies the page verdict and billing status in headers. Its MCP server gives AI agents tools for screenshots, page information, and PDF capture. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000.

FAQ

Does every PDFCrowd account have the same 429 threshold?

No. The allowance depends on the license. Check the current plan or account documentation for its numeric limit.

Does a 429 mean a conversion is already running?

Not necessarily. A 429 identifies request-rate pressure. A 430 identifies too many simultaneous conversions.

How long should I wait after a 429?

The reviewed official sources do not specify a universal wait duration or reset schedule. Use bounded increasing delays, reduce request frequency, and follow any guidance in the response or your account documentation.

Should I upgrade after one limit error?

First determine whether the issue is request rate or concurrency and tune the matching control. Consider a plan change if the required workload persistently exceeds the applicable allowance.