> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blobhub.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Check Definition

Validate a definition against the schema and manifest.

## **POST** `/revisions/:id/data/query` (Command: `check_definition`)

### Request Body

| Parameter       | Type   | Required | Description                                           |
| :-------------- | :----- | :------- | :---------------------------------------------------- |
| `engine`        | string | Yes      | Must be `workflow_blobhub`.                           |
| `command`       | string | Yes      | Must be `check_definition`.                           |
| `definition_id` | string | Yes      | The ID of the definition to check. Must be non-empty. |

### Response

| Parameter | Type   | Description                                 |
| :-------- | :----- | :------------------------------------------ |
| `status`  | string | `success` or `failure`.                     |
| `events`  | array  | Validation events. Never empty — see below. |

**A failed validation is still `HTTP 200`.** The verdict is carried in the response body's `status` field, not in
the HTTP status code. Clients must read `status` — treating `200` as "the definition is valid" accepts every
invalid definition. An HTTP error here means the *request* failed (malformed body, inaccessible definition), not
that validation found problems.

**`status` is `failure` only when an event has type `error`.** Warnings and informational events leave the status
at `success`, so a definition can validate successfully and still return events worth showing to an author.

**`events` is never empty.** When validation finds nothing to report, the platform appends a single `info` event
confirming the flow is ready, so a client can render the result uniformly without special-casing an empty array.

Each event has this shape:

| Field          | Type   | Description                                                          |
| :------------- | :----- | :------------------------------------------------------------------- |
| `type`         | string | `error`, `warning`, or `info`.                                       |
| `message`      | string | Human-readable description of what was found.                        |
| `component_id` | string | Present only when the event is attributable to a specific component. |

### Example

A structurally complete workflow:

<CodeGroup>
  ```json Request theme={null}
  {
    "engine": "workflow_blobhub",
    "command": "check_definition",
    "definition_id": "def_001"
  }
  ```

  ```json Response theme={null}
  {
    "status": "success",
    "events": [
      {
        "type": "info",
        "message": "Verification completed. The flow is ready to be executed"
      }
    ]
  }
  ```
</CodeGroup>

A workflow with no starting point — note the `200`:

<CodeGroup>
  ```json Request theme={null}
  {
    "engine": "workflow_blobhub",
    "command": "check_definition",
    "definition_id": "def_002"
  }
  ```

  ```json Response theme={null}
  {
    "status": "failure",
    "events": [
      {
        "type": "error",
        "message": "`flow.start` component is not found. Execution does not have a starting point"
      }
    ]
  }
  ```
</CodeGroup>

### Notes

* **Validation is not enforced on write.** [Upload Definition](/blob-types/workflow/operations/upload-definition)
  performs no structural validation of workflow documents, so an invalid definition stores successfully. This
  command is where structural problems surface, which is why it must be called explicitly before relying on a
  definition being executable.
* An unknown or inaccessible `definition_id` returns `403 forbidden`, not `404` — an id that does not exist and one
  belonging to another revision are deliberately indistinguishable. An empty `definition_id` returns
  `400 invalid_request_body`.