Workflows API

Manage workflow records, inspect runs, and trigger execution. The create example saves a disabled draft; configure a valid system_spec before enabling a workflow.

Use API authentication for protected requests. Examples use your own resource IDs and a temporary token; saved response examples are synthetic.

Method	Path	Operation
`GET`	`/v1/workflow`	List workflows
`POST`	`/v1/workflow`	Create workflow
`GET`	`/v1/workflow/{id}`	Get workflow
`PUT`	`/v1/workflow/{id}`	Update workflow
`DELETE`	`/v1/workflow/{id}`	Delete workflow
`GET`	`/v1/workflow/{id}/runs`	List workflow runs
`POST`	`/v1/workflow/{id}/runs`	Run workflow
`GET`	`/v1/workflow/{id}/logs`	Get workflow logs

List workflows

GET /v1/workflow

Returns a paginated list of Workflow

Authentication: bearer token and the team header shown below.

Parameters

Name	Location	Required	Description
`X-Tenant-ID`	header	yes	Active team ID. Must match the tenant bound to a diagnostic token.
`page`	query	no	Page number
`per_page`	query	no	Items per page

Request example

Set ADIOS_API_URL=https://api.adios.dev. For protected requests, set ADIOS_ACCESS_TOKEN and ADIOS_TEAM_ID as in the quickstart. Set any additional ADIOS_* variables from your own resource results.

curl --fail-with-body --request GET "$ADIOS_API_URL/v1/workflow" \
  -H "Authorization: Bearer $ADIOS_ACCESS_TOKEN" \
  -H "X-Tenant-ID: $ADIOS_TEAM_ID"

Response: HTTP 200

List of Workflow

Response fields

Field	Type	Description
`data`	array
`data[].created_at`	integer	(Unix timestamp)
`data[].data`	object	Workflow designer state and API-facing metadata
`data[].deleted_at`	integer	(Unix timestamp)
`data[].enabled`	boolean
`data[].owner_id`	string
`data[].region`	string
`data[].status`	string	Allowed: draft, active, disabled, archived, deleted.
`data[].system_spec`	object	Canonical system workflow specification synced to the system backend
`data[].team_id`	string
`data[].title`	string
`data[].updated_at`	integer	(Unix timestamp)
`data[].workflow_id`	string
`pagination`	object
`pagination.page`	integer	Current page number
`pagination.per_page`	integer	Number of items per page
`pagination.total`	integer	Total number of items

Illustrative example; not a live response:

{
  "data": [
    {
      "created_at": 1791072000,
      "data": {},
      "deleted_at": 0,
      "enabled": true,
      "owner_id": "000000000000000000000000001",
      "region": "",
      "status": "draft",
      "system_spec": {},
      "team_id": "000000000000000000000000001",
      "title": "Postman example",
      "updated_at": 1791072000,
      "workflow_id": "000000000000000000000000001"
    }
  ],
  "pagination": {
    "page": 1,
    "per_page": 1,
    "total": 1
  }
}

Create workflow

POST /v1/workflow

Creates a new Workflow

This request changes data or starts an action. Review the target and body before sending it.

Request fields (the body contains an editable example):

Field	Type	Required	Description
`data`	object	no	Workflow designer state and API-facing metadata
`enabled`	boolean	yes	Default: `true`.
`owner_id`	string	no
`region`	string	no	Default: `""`.
`status`	string	yes	Allowed: draft, active, disabled, archived, deleted. Default: `"draft"`.
`system_spec`	object	no	Canonical system workflow specification synced to the system backend
`team_id`	string	yes
`title`	string	yes

Authentication: bearer token and the team header shown below.

Parameters

Name	Location	Required	Description
`X-Tenant-ID`	header	yes	Active team ID. Must match the tenant bound to a diagnostic token.

Request example

curl --fail-with-body --request POST "$ADIOS_API_URL/v1/workflow" \
  -H "Authorization: Bearer $ADIOS_ACCESS_TOKEN" \
  -H "X-Tenant-ID: $ADIOS_TEAM_ID" \
  -H "Content-Type: application/json" \
  --data-binary @- <<'JSON'
{
  "team_id": "YOUR_TEAM_ID",
  "title": "Postman example workflow",
  "status": "draft",
  "enabled": false
}
JSON

Replace YOUR_* body placeholders before sending. The quoted heredoc keeps the JSON literal.

Response: HTTP 201

Workflow created

Response fields

Field	Type	Description
`created_at`	integer	(Unix timestamp)
`data`	object	Workflow designer state and API-facing metadata
`deleted_at`	integer	(Unix timestamp)
`enabled`	boolean
`owner_id`	string
`region`	string
`status`	string	Allowed: draft, active, disabled, archived, deleted.
`system_spec`	object	Canonical system workflow specification synced to the system backend
`team_id`	string
`title`	string
`updated_at`	integer	(Unix timestamp)
`workflow_id`	string

Illustrative example; not a live response:

{
  "created_at": 1791072000,
  "data": {},
  "deleted_at": 0,
  "enabled": true,
  "owner_id": "000000000000000000000000001",
  "region": "",
  "status": "draft",
  "system_spec": {},
  "team_id": "000000000000000000000000001",
  "title": "Postman example",
  "updated_at": 1791072000,
  "workflow_id": "000000000000000000000000001"
}

Get workflow

GET /v1/workflow/{id}

Returns a single Workflow

Set workflow_id using IDs from your own API responses.

Authentication: bearer token and the team header shown below.

Parameters

Name	Location	Required	Description
`id`	path	yes	Resource identifier from your team's API results.
`X-Tenant-ID`	header	yes	Active team ID. Must match the tenant bound to a diagnostic token.

Request example

curl --fail-with-body --request GET "$ADIOS_API_URL/v1/workflow/${ADIOS_WORKFLOW_ID}" \
  -H "Authorization: Bearer $ADIOS_ACCESS_TOKEN" \
  -H "X-Tenant-ID: $ADIOS_TEAM_ID"

Response: HTTP 200

Workflow

Response fields

Field	Type	Description
`created_at`	integer	(Unix timestamp)
`data`	object	Workflow designer state and API-facing metadata
`deleted_at`	integer	(Unix timestamp)
`enabled`	boolean
`owner_id`	string
`region`	string
`status`	string	Allowed: draft, active, disabled, archived, deleted.
`system_spec`	object	Canonical system workflow specification synced to the system backend
`team_id`	string
`title`	string
`updated_at`	integer	(Unix timestamp)
`workflow_id`	string

Illustrative example; not a live response:

{
  "created_at": 1791072000,
  "data": {},
  "deleted_at": 0,
  "enabled": true,
  "owner_id": "000000000000000000000000001",
  "region": "",
  "status": "draft",
  "system_spec": {},
  "team_id": "000000000000000000000000001",
  "title": "Postman example",
  "updated_at": 1791072000,
  "workflow_id": "000000000000000000000000001"
}

Update workflow

PUT /v1/workflow/{id}

Updates an existing Workflow

Set workflow_id using IDs from your own API responses.

This request changes data or starts an action. Review the target and body before sending it.

Request fields (the body contains an editable example):

Field	Type	Required	Description
`data`	object	no	Workflow designer state and API-facing metadata
`enabled`	boolean	yes	Default: `true`.
`owner_id`	string	no
`region`	string	no	Default: `""`.
`status`	string	yes	Allowed: draft, active, disabled, archived, deleted. Default: `"draft"`.
`system_spec`	object	no	Canonical system workflow specification synced to the system backend
`team_id`	string	yes
`title`	string	yes

Authentication: bearer token and the team header shown below.

Parameters

Name	Location	Required	Description
`id`	path	yes	Resource identifier from your team's API results.
`X-Tenant-ID`	header	yes	Active team ID. Must match the tenant bound to a diagnostic token.

Request example

curl --fail-with-body --request PUT "$ADIOS_API_URL/v1/workflow/${ADIOS_WORKFLOW_ID}" \
  -H "Authorization: Bearer $ADIOS_ACCESS_TOKEN" \
  -H "X-Tenant-ID: $ADIOS_TEAM_ID" \
  -H "Content-Type: application/json" \
  --data-binary @- <<'JSON'
{
  "team_id": "YOUR_TEAM_ID",
  "title": "Postman example workflow",
  "status": "draft",
  "enabled": false
}
JSON

Replace YOUR_* body placeholders before sending. The quoted heredoc keeps the JSON literal.

Response: HTTP 200

Workflow updated

Response fields

Field	Type	Description
`created_at`	integer	(Unix timestamp)
`data`	object	Workflow designer state and API-facing metadata
`deleted_at`	integer	(Unix timestamp)
`enabled`	boolean
`owner_id`	string
`region`	string
`status`	string	Allowed: draft, active, disabled, archived, deleted.
`system_spec`	object	Canonical system workflow specification synced to the system backend
`team_id`	string
`title`	string
`updated_at`	integer	(Unix timestamp)
`workflow_id`	string

Illustrative example; not a live response:

{
  "created_at": 1791072000,
  "data": {},
  "deleted_at": 0,
  "enabled": true,
  "owner_id": "000000000000000000000000001",
  "region": "",
  "status": "draft",
  "system_spec": {},
  "team_id": "000000000000000000000000001",
  "title": "Postman example",
  "updated_at": 1791072000,
  "workflow_id": "000000000000000000000000001"
}

Delete workflow

DELETE /v1/workflow/{id}

Deletes a Workflow

Set workflow_id using IDs from your own API responses.

This request changes data or starts an action. Review the target and body before sending it.

Authentication: bearer token and the team header shown below.

Parameters

Name	Location	Required	Description
`id`	path	yes	Resource identifier from your team's API results.
`X-Tenant-ID`	header	yes	Active team ID. Must match the tenant bound to a diagnostic token.

Request example

curl --fail-with-body --request DELETE "$ADIOS_API_URL/v1/workflow/${ADIOS_WORKFLOW_ID}" \
  -H "Authorization: Bearer $ADIOS_ACCESS_TOKEN" \
  -H "X-Tenant-ID: $ADIOS_TEAM_ID"

Response: HTTP 200

Resource deleted.

Response fields

Field	Type	Description
`message`	string

Illustrative example; not a live response:

{
  "message": "Deleted successfully"
}

List workflow runs

GET /v1/workflow/{id}/runs

List runs belonging to the selected workflow.

Set workflow_id using IDs from your own API responses.

Authentication: bearer token and the team header shown below.

Parameters

Name	Location	Required	Description
`id`	path	yes	Resource identifier from your team's API results.
`X-Tenant-ID`	header	yes	Active team ID. Must match the tenant bound to a diagnostic token.

Request example

curl --fail-with-body --request GET "$ADIOS_API_URL/v1/workflow/${ADIOS_WORKFLOW_ID}/runs" \
  -H "Authorization: Bearer $ADIOS_ACCESS_TOKEN" \
  -H "X-Tenant-ID: $ADIOS_TEAM_ID"

Response: HTTP 200

Successful response. Inspect returned state for operations that start asynchronous work.

A complete response-body schema is not published for this custom operation. Inspect the returned content and status; no payload is assumed here.

Run workflow

POST /v1/workflow/{id}/runs

Start a configured workflow. Put workflow input in payload. This may perform external actions defined by the workflow and requires a paid subscription.

Set workflow_id using IDs from your own API responses.

This request changes data or starts an action. Review the target and body before sending it.

Authentication: bearer token and the team header shown below.

Parameters

Name	Location	Required	Description
`id`	path	yes	Resource identifier from your team's API results.
`X-Tenant-ID`	header	yes	Active team ID. Must match the tenant bound to a diagnostic token.

Request example

curl --fail-with-body --request POST "$ADIOS_API_URL/v1/workflow/${ADIOS_WORKFLOW_ID}/runs" \
  -H "Authorization: Bearer $ADIOS_ACCESS_TOKEN" \
  -H "X-Tenant-ID: $ADIOS_TEAM_ID" \
  -H "Content-Type: application/json" \
  --data-binary @- <<'JSON'
{
  "payload": {}
}
JSON

Replace YOUR_* body placeholders before sending. The quoted heredoc keeps the JSON literal.

Response: HTTP 201

Successful response. Inspect returned state for operations that start asynchronous work.

A complete response-body schema is not published for this custom operation. Inspect the returned content and status; no payload is assumed here.

Get workflow logs

GET /v1/workflow/{id}/logs

Read workflow lifecycle logs.

Set workflow_id using IDs from your own API responses.

Authentication: bearer token and the team header shown below.

Parameters

Name	Location	Required	Description
`id`	path	yes	Resource identifier from your team's API results.
`X-Tenant-ID`	header	yes	Active team ID. Must match the tenant bound to a diagnostic token.

Request example

curl --fail-with-body --request GET "$ADIOS_API_URL/v1/workflow/${ADIOS_WORKFLOW_ID}/logs" \
  -H "Authorization: Bearer $ADIOS_ACCESS_TOKEN" \
  -H "X-Tenant-ID: $ADIOS_TEAM_ID"

Response: HTTP 200

Successful response. Inspect returned state for operations that start asynchronous work.

A complete response-body schema is not published for this custom operation. Inspect the returned content and status; no payload is assumed here.