Run up to 10 operations in one request.
Executes several search / dossier / chat operations in a single round trip.
Batching changes the transport and nothing else. Every item is authenticated by the same key, checked against the same scope, counted against the same per-operation rate limit, served from the same dossier cache, and billed exactly as it would have been on its own - each item settles from the provider work it actually performs, while cached dossiers remain free. Items run sequentially.
A batch of 10 is the maximum; queue anything larger, or anything slow, with POST /api/v1/jobs.
The response is 200 whenever the batch itself was valid and authenticated, even if every item failed: each result carries its own status and its own error body. An Idempotency-Key is extended per item (<key>:<id>), so retrying a partially failed batch replays the items that succeeded instead of re-charging them.
Request
- Base URL: https://deepsearch.app
- URL: https://deepsearch.app/api/v1/batch
- Auth: HTTP bearer
Headers
Extended per item as <key>:<item id> and replayed item by item.
Run against deterministic sandbox fixtures, unmetered. Equivalent to sandbox: true in the body.
Optional name/version naming the calling client. Self-reported and used only for aggregate analytics: it never affects authentication, rate limits, billing or the response. The official SDKs and CLI send it; any other name is counted as a custom client.
Request body
Response
The batch ran. Read each result's status - a 200 envelope does not mean every item succeeded.
Changes
No recorded changes to this operation across all 1 revision of this API.