Making requests

cloro offers two ways to call the API: synchronous requests, where you wait for the result on the same connection, and asynchronous requests, where you submit a task and retrieve the result later.

Synchronous requests

Synchronous endpoints return the full result in the same HTTP response, so the request has to fit inside your client’s timeout. See Synchronous requests for the request and response structure, common parameters, and code examples.

Asynchronous requests

Asynchronous endpoints accept a task, return a taskId immediately, and process the work in the background. You retrieve the result via webhook (recommended) or by polling. See Asynchronous requests for the two-step submit-and-fetch flow, task states, queue limits, and request prioritization.

When to use which

Common questions

How long should one request take?

Typical end-to-end times, measured over the last seven days of production traffic: A request to an AI assistant (ChatGPT, Gemini) drives a real browser session (how cloro retrieves data): it loads the surface, submits the prompt, waits for the answer to finish streaming and parses the rendered page, often over several page loads when the surface defers its sources or product cards. A Google SERP is one page load, so it lands in seconds. An AI surface has to generate its answer before there is anything to read, and that generation time is the bulk of the wait. The spread moves with the provider’s own load, so treat these as the shape rather than a guarantee. Elmo publishes an independent comparison of cloro and other scraping APIs for these engines, re-measured every six hours on the same prompts.

Why are my requests slower than expected?

Beyond the generation time above, latency comes from:

• Queue depth (async requests only): set by your plan’s concurrency limit and your current queue size
• Geographic routing: requests route through region-specific infrastructure, which may differ in latency depending on the country parameter you specify
• Provider load: peak hours on the provider’s side lengthen generation

If a batch takes far longer than one request times the number of prompts, the cause is almost always concurrency rather than any single request: on one slot the prompts run one after another. Upgrading your plan raises concurrency, which drains the async queue faster. To measure a single request, read its latency header.

Can I get faster processing for high-volume workloads?

Yes — the larger the plan, the greater the concurrency assigned to it. For async requests, higher concurrency means more tasks processed at once and shorter queue waits. For sync requests, it means you can send more simultaneous requests without hitting limits.

How do I submit many requests in one call?

Use the batch endpoint. It takes up to 500 tasks in a single HTTP request and validates each task independently, so one bad task doesn’t block the rest. cloro queues the tasks, within your queue limit, and runs them up to your plan’s concurrency limit; retrieve results with webhooks or polling. For which pattern to use once you’re submitting at volume — async with webhooks, or sync with concurrent workers — see the concurrency guide, which has code examples for both.