# Error response format

When a request fails or encounters issues, the API returns a standardized **error response object** in JSON format.
This structure is consistent across endpoints, ensuring clients can reliably parse and handle errors.

## Example


```json
{
  "status": "error",
  "errors": [
    {
      "code": "invalid_field_value",
      "message": "The 'id' field must be unique.",
      "field": "id",
      "type": "validation"
    }
  ],
  "requestId": "req-uuid-456"
}
```

## Top-level fields

| Field | Type | Description |
|  --- | --- | --- |
| **status** | string | Always `error` for error responses. Use this to quickly distinguish error responses from successful responses. |
| **errors** | array | **Always an array**, even when only one error is present. Contains one or more error objects that describe what went wrong. |
| **requestId** | string | Unique identifier for the request (e.g., a UUID). Log this value and include it when contacting support—it enables precise tracing and debugging. |


## Error object fields

| Field | Type | Description |
|  --- | --- | --- |
| **code** | string | **Machine-readable** error identifier (e.g., `invalid_field_value`, `not_found`, `rate_limited`). Use this for programmatic handling. See the [Errors → Response codes](/api/errors/error-codes) reference for the full list. |
| **message** | string | **Human-readable** explanation of the error. Intended for developers; not guaranteed to be stable for end-user display or localization. |
| **field** | string | *(Optional; operation-specific)* The dataset field related to the error when applicable—commonly returned for validation/ingestion errors. Omitted for errors not tied to a specific field. |
| **type** | string | *(Optional; operation-specific)* Broad category that adds context, such as `validation`. Useful for grouping errors beyond the specific code. |