Authentication
Databar uses API keys to allow access to the API. Include your key in thex-apikey header on every request.
Base URL
All API requests should be made to:Async Pattern
Some operations (bulk enrichments, waterfalls) run asynchronously. The flow is:1
Submit the request
Call a run or bulk-run endpoint. You’ll receive a
task_id in the response.2
Poll for results
Call
GET /v1/tasks/{task_id} with the task_id. The status field will be
processing, completed, partially_completed or failed. For a bulk run the
response also carries progress with per-input counts, so you can see it advancing.
A task you no longer want can be stopped with POST /v1/tasks/{task_id}/cancel.3
Retrieve your data
When
status is completed, the data field contains your results. For
bulk runs, data is aligned to your inputs: one element per input, in the
same order you submitted them, with null for inputs that returned no data
(so len(data) equals the number of inputs and data[i] is the result for
input i). A single (non-bulk) run returns the result object directly.Pagination
TheGET /v1/table/{table_uuid}/rows endpoint supports pagination:
The response includes
has_next_page and total_count to help you iterate.
Error Handling
The API uses standard HTTP status codes. All error responses return a JSON body with adetail field describing the issue.
Common Error Codes
Error Response Formats
Bad input (400 and 422) uses one envelope.error is a stable code, detail is a string you can show to a person. Extra keys depend on the code.
Parameter validation (400):
BATCH_TOO_LARGE, UNKNOWN_COLUMNS, INVALID_DATA, INVALID_FILTER, INVALID_PAGINATION, DUPLICATE_KEYS, PER_PAGE_TOO_LARGE.
Schema validation (422) — the JSON does not match the endpoint’s body: