Response outcomes
The examples here describe the planned contract, not a live endpoint.
Succeeded
Section titled “Succeeded”The selected, eligible scope was checked. Results may exist or the completed search may have found no matches. An empty successful search must describe what was checked.
Partial
Section titled “Partial”The caller explicitly allowed partial delivery and useful records were returned, while some sources were excluded or failed. Per-source outcomes identify the gaps. A partial response is not a claim of full coverage.
Failed
Section titled “Failed”The task could not deliver an acceptable result. It is not reported as a successful empty search. For Job Scraper, nothing delivered means no business charge.
Refused before execution
Section titled “Refused before execution”A request can be refused because its input, filters, authorization or spending ceiling do not allow it to proceed. It does not create a new task or task charge. A request error while looking up an existing task does not erase that original task’s billing history.
Running
Section titled “Running”An accepted task can still be running. Do not treat the absence of terminal results as an empty search. Follow the task handle rather than submitting another paid task.
Fields and errors
Section titled “Fields and errors”The planned response uses fields including requestId, jobId, status, data, sourceOutcomes and usage. Only applicable fields appear in each branch. Errors and warnings must be structured and actionable. Keep the request identifier when reporting a problem; never send API keys.