Skip to main content
This API implements the standard async task contract. For the endpoints it supports, request and response schemas are unchanged, so a working client usually needs no code edits.

​
The migration

Point your API-key constant at a querying.ai key. Your webhook URL, idempotency keys, task types, and response parsing all stay as they are.

​
What is implemented

Supported

POST /v1/async/taskPOST /v1/async/task/batchGET /v1/async/task/{id}Webhook callbacks

Not implemented

/v1/monitor/* synchronous endpoints/v1/async/status
The synchronous /v1/monitor/* family is deliberately absent. Every engine here runs asynchronously; a request that blocks for the time a query can take is not a shape this service offers.

​
Where behaviour differs

There is no per-key rate limit. For large volumes, use batch submission to reduce round trips.See Regions and best practices.
credits is present on every response as part of the envelope. Submit and poll responses report { "creditsToCharge": 0, "creditsCharged": 0 }; webhooks report the per-engine credit cost (1–3 credits depending on engine).Failed tasks are not charged. Credit balances are visible on the dashboard.
A few combinations cannot be served at all — CHATGPT/PERPLEXITY/GEMINI into CN, GEMINI into DE/GB/IR. Those fail immediately with 422 REGION_UNSUPPORTED rather than being accepted. 422 REGION_UNAVAILABLE covers the transient version of the same thing.A client that assumes every well-formed submission is accepted needs a branch here. See Regions.
The payload.include flags are accepted, but most engines here return a fixed-shape response and ignore them. Only ChatGPT honours the full set; GEMINI honours markdown and rawResponse only.Requesting html from Gemini, for instance, is silently ignored — no error, no field. See the flag support table.
Error handling is otherwise conventional — validation failures return 400, 401 reports MISSING_API_KEY, 404 reports RESOURCE_NOT_FOUND, and details names the offending field.The one addition is the 422 pair (REGION_UNSUPPORTED, REGION_UNAVAILABLE) described above. We tell you up front when a region cannot be served, so a client that has never had to handle a 422 will start seeing them.
GET /v1/async/task/{id} on a FAILED task returns a top-level error field that the task-status schema does not otherwise define — and it is a plain string, not the {code, message, timestamp} object used by request-level errors.
A client that treats a truthy body.error as a failed request will misread a successfully-retrieved failed task. Branch on task.status instead.
These behaviours were established by calling this API, not by reading a schema. Where a published spec and a live response ever disagree, the live response is what these pages document.

​
Picking the right taskType

If your current integration calls a per-engine endpoint, the engine name maps onto a taskType:
GOOGLE meaning “AI Overview” is a naming convention, not a Google product name. The response is a SERP envelope with aioverview as a nullable member — see the GOOGLE shape.

​
Verifying the cutover

Run your existing integration and this one in parallel for a window, and diff the fields you actually consume — in practice response.text, response.sources[], and response.markdown. A shadow comparison catches shape drift that a schema check will not, such as a source list that is populated but ordered differently.