API de flujos de trabajo

Gestiona registros de flujos de trabajo, inspecciona sus ejecuciones e inicia su ejecución. El ejemplo de creación guarda un borrador deshabilitado; configura un system_spec válido antes de activar un flujo de trabajo.

Usa Autenticación de la API para las solicitudes protegidas. Los ejemplos usan tus propios IDs de recursos y un token temporal; las respuestas de ejemplo guardadas son sintéticas.

Método	Ruta	Operación
`GET`	`/v1/workflow`	Listar flujos de trabajo
`POST`	`/v1/workflow`	Crear flujo de trabajo
`GET`	`/v1/workflow/{id}`	Obtener flujo de trabajo
`PUT`	`/v1/workflow/{id}`	Actualizar flujo de trabajo
`DELETE`	`/v1/workflow/{id}`	Eliminar el flujo de trabajo
`GET`	`/v1/workflow/{id}/runs`	Listar ejecuciones del flujo de trabajo
`POST`	`/v1/workflow/{id}/runs`	Ejecutar flujo de trabajo
`GET`	`/v1/workflow/{id}/logs`	Obtener registros de flujo de trabajo

Listar flujos de trabajo

GET /v1/workflow

Devuelve una lista paginada de Workflow

Autenticación: token bearer y la cabecera de equipo que se muestra a continuación.

Parámetros

Nombre	Ubicación	Obligatorio	Descripción
`X-Tenant-ID`	cabecera	sí	ID del equipo activo. Debe coincidir con el tenant vinculado al token de diagnóstico.
`page`	consulta	no	Número de página
`per_page`	consulta	no	Elementos por página

Ejemplo de solicitud

Configura ADIOS_API_URL=https://api.adios.dev. Para las solicitudes protegidas, configura ADIOS_ACCESS_TOKEN y ADIOS_TEAM_ID como en el inicio rápido. Configura las variables adicionales ADIOS_* a partir de los resultados de tus propios recursos.

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

Respuesta: HTTP 200

Lista de Workflow

Campos de respuesta

Campo	Tipo	Descripción
`data`	array
`data[].created_at`	integer	(marca de tiempo Unix)
`data[].data`	object	Estado del diseñador de flujos de trabajo y metadatos expuestos por la API
`data[].deleted_at`	integer	(marca de tiempo Unix)
`data[].enabled`	boolean
`data[].owner_id`	string
`data[].region`	string
`data[].status`	string	Valores permitidos: draft, active, disabled, archived, deleted.
`data[].system_spec`	object	Especificación canónica del flujo de trabajo del sistema sincronizada con el backend del sistema
`data[].team_id`	string
`data[].title`	string
`data[].updated_at`	integer	(marca de tiempo Unix)
`data[].workflow_id`	string
`pagination`	object
`pagination.page`	integer	Número de página actual
`pagination.per_page`	integer	Número de elementos por página
`pagination.total`	integer	Número total de elementos

Ejemplo ilustrativo; no es una respuesta real:

{
  "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
  }
}

Crear flujo de trabajo

POST /v1/workflow

Crea un nuevo Workflow

Esta solicitud modifica datos o inicia una acción. Revisa el destino y el cuerpo antes de enviarla.

Campos de la solicitud (el cuerpo contiene un ejemplo editable):

Campo	Tipo	Obligatorio	Descripción
`data`	object	no	Estado del diseñador de flujos de trabajo y metadatos expuestos por la API
`enabled`	boolean	sí	Valor predeterminado: `true`.
`owner_id`	string	no
`region`	string	no	Valor predeterminado: `""`.
`status`	string	sí	Valores permitidos: draft, active, disabled, archived, deleted. Valor predeterminado: `"draft"`.
`system_spec`	object	no	Especificación canónica del flujo de trabajo del sistema sincronizada con el backend del sistema
`team_id`	string	sí
`title`	string	sí

Autenticación: token bearer y la cabecera de equipo que se muestra a continuación.

Parámetros

Nombre	Ubicación	Obligatorio	Descripción
`X-Tenant-ID`	cabecera	sí	ID del equipo activo. Debe coincidir con el tenant vinculado al token de diagnóstico.

Ejemplo de solicitud

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

Reemplaza los marcadores YOUR_* del cuerpo antes de enviar la solicitud. El heredoc entrecomillado conserva el JSON literal.

Respuesta: HTTP 201

Workflow creado

Campos de respuesta

Campo	Tipo	Descripción
`created_at`	integer	(marca de tiempo Unix)
`data`	object	Estado del diseñador de flujos de trabajo y metadatos expuestos por la API
`deleted_at`	integer	(marca de tiempo Unix)
`enabled`	boolean
`owner_id`	string
`region`	string
`status`	string	Valores permitidos: draft, active, disabled, archived, deleted.
`system_spec`	object	Especificación canónica del flujo de trabajo del sistema sincronizada con el backend del sistema
`team_id`	string
`title`	string
`updated_at`	integer	(marca de tiempo Unix)
`workflow_id`	string

Ejemplo ilustrativo; no es una respuesta real:

{
  "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"
}

Obtener flujo de trabajo

GET /v1/workflow/{id}

Devuelve un único Workflow

Configura workflow_id usando IDs de tus propias respuestas de la API.

Autenticación: token bearer y la cabecera de equipo que se muestra a continuación.

Parámetros

Nombre	Ubicación	Obligatorio	Descripción
`id`	ruta	sí	Identificador del recurso obtenido de los resultados de la API de tu equipo.
`X-Tenant-ID`	cabecera	sí	ID del equipo activo. Debe coincidir con el tenant vinculado al token de diagnóstico.

Ejemplo de solicitud

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"

Respuesta: HTTP 200

Flujo de trabajo

Campos de respuesta

Campo	Tipo	Descripción
`created_at`	integer	(marca de tiempo Unix)
`data`	object	Estado del diseñador de flujos de trabajo y metadatos expuestos por la API
`deleted_at`	integer	(marca de tiempo Unix)
`enabled`	boolean
`owner_id`	string
`region`	string
`status`	string	Valores permitidos: draft, active, disabled, archived, deleted.
`system_spec`	object	Especificación canónica del flujo de trabajo del sistema sincronizada con el backend del sistema
`team_id`	string
`title`	string
`updated_at`	integer	(marca de tiempo Unix)
`workflow_id`	string

Ejemplo ilustrativo; no es una respuesta real:

{
  "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"
}

Actualizar flujo de trabajo

PUT /v1/workflow/{id}

Actualiza un Workflow existente

Configura workflow_id usando IDs de tus propias respuestas de la API.

Esta solicitud modifica datos o inicia una acción. Revisa el destino y el cuerpo antes de enviarla.

Campos de la solicitud (el cuerpo contiene un ejemplo editable):

Campo	Tipo	Obligatorio	Descripción
`data`	object	no	Estado del diseñador de flujos de trabajo y metadatos expuestos por la API
`enabled`	boolean	sí	Valor predeterminado: `true`.
`owner_id`	string	no
`region`	string	no	Valor predeterminado: `""`.
`status`	string	sí	Valores permitidos: draft, active, disabled, archived, deleted. Valor predeterminado: `"draft"`.
`system_spec`	object	no	Especificación canónica del flujo de trabajo del sistema sincronizada con el backend del sistema
`team_id`	string	sí
`title`	string	sí

Autenticación: token bearer y la cabecera de equipo que se muestra a continuación.

Parámetros

Nombre	Ubicación	Obligatorio	Descripción
`id`	ruta	sí	Identificador del recurso obtenido de los resultados de la API de tu equipo.
`X-Tenant-ID`	cabecera	sí	ID del equipo activo. Debe coincidir con el tenant vinculado al token de diagnóstico.

Ejemplo de solicitud

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

Reemplaza los marcadores YOUR_* del cuerpo antes de enviar la solicitud. El heredoc entrecomillado conserva el JSON literal.

Respuesta: HTTP 200

Workflow actualizado

Campos de respuesta

Campo	Tipo	Descripción
`created_at`	integer	(marca de tiempo Unix)
`data`	object	Estado del diseñador de flujos de trabajo y metadatos expuestos por la API
`deleted_at`	integer	(marca de tiempo Unix)
`enabled`	boolean
`owner_id`	string
`region`	string
`status`	string	Valores permitidos: draft, active, disabled, archived, deleted.
`system_spec`	object	Especificación canónica del flujo de trabajo del sistema sincronizada con el backend del sistema
`team_id`	string
`title`	string
`updated_at`	integer	(marca de tiempo Unix)
`workflow_id`	string

Ejemplo ilustrativo; no es una respuesta real:

{
  "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"
}

Eliminar el flujo de trabajo

DELETE /v1/workflow/{id}

Elimina un Workflow

Configura workflow_id usando IDs de tus propias respuestas de la API.

Esta solicitud modifica datos o inicia una acción. Revisa el destino y el cuerpo antes de enviarla.

Autenticación: token bearer y la cabecera de equipo que se muestra a continuación.

Parámetros

Nombre	Ubicación	Obligatorio	Descripción
`id`	ruta	sí	Identificador del recurso obtenido de los resultados de la API de tu equipo.
`X-Tenant-ID`	cabecera	sí	ID del equipo activo. Debe coincidir con el tenant vinculado al token de diagnóstico.

Ejemplo de solicitud

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"

Respuesta: HTTP 200

Recurso eliminado.

Campos de respuesta

Campo	Tipo	Descripción
`message`	string

Ejemplo ilustrativo; no es una respuesta real:

{
  "message": "Deleted successfully"
}

Listar ejecuciones del flujo de trabajo

GET /v1/workflow/{id}/runs

Lista las ejecuciones del flujo de trabajo seleccionado.

Configura workflow_id usando IDs de tus propias respuestas de la API.

Autenticación: token bearer y la cabecera de equipo que se muestra a continuación.

Parámetros

Nombre	Ubicación	Obligatorio	Descripción
`id`	ruta	sí	Identificador del recurso obtenido de los resultados de la API de tu equipo.
`X-Tenant-ID`	cabecera	sí	ID del equipo activo. Debe coincidir con el tenant vinculado al token de diagnóstico.

Ejemplo de solicitud

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"

Respuesta: HTTP 200

Respuesta correcta. Inspecciona el estado devuelto por las operaciones que inician trabajo asíncrono.

No se publica un esquema completo del cuerpo de respuesta para esta operación personalizada. Inspecciona el contenido y el estado devueltos; aquí no se presupone ningún payload.

Ejecutar flujo de trabajo

POST /v1/workflow/{id}/runs

Inicia un flujo de trabajo configurado. Introduce los datos de entrada en payload. Esto puede realizar las acciones externas definidas por el flujo de trabajo y requiere una suscripción de pago.

Configura workflow_id usando IDs de tus propias respuestas de la API.

Esta solicitud modifica datos o inicia una acción. Revisa el destino y el cuerpo antes de enviarla.

Autenticación: token bearer y la cabecera de equipo que se muestra a continuación.

Parámetros

Nombre	Ubicación	Obligatorio	Descripción
`id`	ruta	sí	Identificador del recurso obtenido de los resultados de la API de tu equipo.
`X-Tenant-ID`	cabecera	sí	ID del equipo activo. Debe coincidir con el tenant vinculado al token de diagnóstico.

Ejemplo de solicitud

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

Reemplaza los marcadores YOUR_* del cuerpo antes de enviar la solicitud. El heredoc entrecomillado conserva el JSON literal.

Respuesta: HTTP 201

Respuesta correcta. Inspecciona el estado devuelto por las operaciones que inician trabajo asíncrono.

No se publica un esquema completo del cuerpo de respuesta para esta operación personalizada. Inspecciona el contenido y el estado devueltos; aquí no se presupone ningún payload.

Obtener registros de flujo de trabajo

GET /v1/workflow/{id}/logs

Lee los registros del ciclo de vida del flujo de trabajo.

Configura workflow_id usando IDs de tus propias respuestas de la API.

Autenticación: token bearer y la cabecera de equipo que se muestra a continuación.

Parámetros

Nombre	Ubicación	Obligatorio	Descripción
`id`	ruta	sí	Identificador del recurso obtenido de los resultados de la API de tu equipo.
`X-Tenant-ID`	cabecera	sí	ID del equipo activo. Debe coincidir con el tenant vinculado al token de diagnóstico.

Ejemplo de solicitud

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"

Respuesta: HTTP 200

Respuesta correcta. Inspecciona el estado devuelto por las operaciones que inician trabajo asíncrono.

No se publica un esquema completo del cuerpo de respuesta para esta operación personalizada. Inspecciona el contenido y el estado devueltos; aquí no se presupone ningún payload.