API des workflows

Gérez les enregistrements de workflows, inspectez les exécutions et déclenchez-les. L’exemple de création enregistre un brouillon désactivé ; configurez un system_spec valide avant d’activer le workflow.

Utiliser Authentification API pour les requêtes protégées. Les exemples utilisent vos propres ID de ressources et un jeton temporaire ; les exemples de réponses enregistrés sont synthétiques.

Méthode	Chemin	Opération
`GET`	`/v1/workflow`	Lister les workflows
`POST`	`/v1/workflow`	Créer le workflow
`GET`	`/v1/workflow/{id}`	Obtenir le flux de travail
`PUT`	`/v1/workflow/{id}`	Mettre à jour le flux de travail
`DELETE`	`/v1/workflow/{id}`	Supprimer le flux de travail
`GET`	`/v1/workflow/{id}/runs`	Lister les exécutions de workflow
`POST`	`/v1/workflow/{id}/runs`	Exécuter le flux de travail
`GET`	`/v1/workflow/{id}/logs`	Obtenir les journaux de flux de travail

Lister les workflows

GET /v1/workflow

Renvoie une liste paginée de Workflow

Authentification : jeton bearer et en-tête d’équipe présentés ci-dessous.

Paramètres

Nom	Emplacement	Requis	Description
`X-Tenant-ID`	en-tête	oui	ID de l’équipe active. Doit correspondre au tenant lié au jeton de diagnostic.
`page`	requête	non	Numéro de page
`per_page`	requête	non	Éléments par page

Exemple de requête

Définissez ADIOS_API_URL=https://api.adios.dev. Pour les requêtes protégées, définissez ADIOS_ACCESS_TOKEN et ADIOS_TEAM_ID comme dans le démarrage rapide. Définissez les autres variables ADIOS_* à partir des résultats de vos propres ressources.

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

Réponse : HTTP 200

Liste de Workflow

Champs de réponse

Champ	Type	Description
`data`	tableau
`data[].created_at`	entier	(horodatage Unix)
`data[].data`	objet	État du concepteur de workflows et métadonnées exposées par l’API
`data[].deleted_at`	entier	(horodatage Unix)
`data[].enabled`	booléen
`data[].owner_id`	chaîne
`data[].region`	chaîne
`data[].status`	chaîne	Valeurs autorisées : draft, active, disabled, archived, deleted.
`data[].system_spec`	objet	Spécification canonique du workflow système, synchronisée avec le backend du système
`data[].team_id`	chaîne
`data[].title`	chaîne
`data[].updated_at`	entier	(horodatage Unix)
`data[].workflow_id`	chaîne
`pagination`	objet
`pagination.page`	entier	Numéro de page actuel
`pagination.per_page`	entier	Nombre d’éléments par page
`pagination.total`	entier	Nombre total d’éléments

Exemple illustratif ; il ne s’agit pas d’une réponse réelle :

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

Créer le workflow

POST /v1/workflow

Crée un nouvel objet Workflow

Cette requête modifie des données ou lance une action. Vérifiez la cible et le corps avant de l’envoyer.

Champs de la requête (le corps contient un exemple modifiable) :

Champ	Type	Requis	Description
`data`	objet	non	État du concepteur de workflows et métadonnées exposées par l’API
`enabled`	booléen	oui	Valeur par défaut : `true`.
`owner_id`	chaîne	non
`region`	chaîne	non	Valeur par défaut : `""`.
`status`	chaîne	oui	Valeurs autorisées : draft, active, disabled, archived, deleted. Valeur par défaut : `"draft"`.
`system_spec`	objet	non	Spécification canonique du workflow système, synchronisée avec le backend du système
`team_id`	chaîne	oui
`title`	chaîne	oui

Authentification : jeton bearer et en-tête d’équipe présentés ci-dessous.

Paramètres

Nom	Emplacement	Requis	Description
`X-Tenant-ID`	en-tête	oui	ID de l’équipe active. Doit correspondre au tenant lié au jeton de diagnostic.

Exemple de requête

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

Remplacez YOUR_* du corps avant l’envoi. Le heredoc entre guillemets préserve le JSON littéral.

Réponse : HTTP 201

Flux de travail créé

Champs de réponse

Champ	Type	Description
`created_at`	entier	(horodatage Unix)
`data`	objet	État du concepteur de workflows et métadonnées exposées par l’API
`deleted_at`	entier	(horodatage Unix)
`enabled`	booléen
`owner_id`	chaîne
`region`	chaîne
`status`	chaîne	Valeurs autorisées : draft, active, disabled, archived, deleted.
`system_spec`	objet	Spécification canonique du workflow système, synchronisée avec le backend du système
`team_id`	chaîne
`title`	chaîne
`updated_at`	entier	(horodatage Unix)
`workflow_id`	chaîne

Exemple illustratif ; il ne s’agit pas d’une réponse réelle :

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

Obtenir le flux de travail

GET /v1/workflow/{id}

Renvoie un seul Workflow

Définissez workflow_id en utilisant les ID de vos propres réponses API.

Authentification : jeton bearer et en-tête d’équipe présentés ci-dessous.

Paramètres

Nom	Emplacement	Requis	Description
`id`	chemin	oui	Identifiant de ressource issu des résultats API de votre équipe.
`X-Tenant-ID`	en-tête	oui	ID de l’équipe active. Doit correspondre au tenant lié au jeton de diagnostic.

Exemple de requête

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"

Réponse : HTTP 200

Flux de travail

Champs de réponse

Champ	Type	Description
`created_at`	entier	(horodatage Unix)
`data`	objet	État du concepteur de workflows et métadonnées exposées par l’API
`deleted_at`	entier	(horodatage Unix)
`enabled`	booléen
`owner_id`	chaîne
`region`	chaîne
`status`	chaîne	Valeurs autorisées : draft, active, disabled, archived, deleted.
`system_spec`	objet	Spécification canonique du workflow système, synchronisée avec le backend du système
`team_id`	chaîne
`title`	chaîne
`updated_at`	entier	(horodatage Unix)
`workflow_id`	chaîne

Exemple illustratif ; il ne s’agit pas d’une réponse réelle :

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

Mettre à jour le flux de travail

PUT /v1/workflow/{id}

Met à jour un objet Workflow existant

Définissez workflow_id en utilisant les ID de vos propres réponses API.

Cette requête modifie des données ou lance une action. Vérifiez la cible et le corps avant de l’envoyer.

Champs de la requête (le corps contient un exemple modifiable) :

Champ	Type	Requis	Description
`data`	objet	non	État du concepteur de workflows et métadonnées exposées par l’API
`enabled`	booléen	oui	Valeur par défaut : `true`.
`owner_id`	chaîne	non
`region`	chaîne	non	Valeur par défaut : `""`.
`status`	chaîne	oui	Valeurs autorisées : draft, active, disabled, archived, deleted. Valeur par défaut : `"draft"`.
`system_spec`	objet	non	Spécification canonique du workflow système, synchronisée avec le backend du système
`team_id`	chaîne	oui
`title`	chaîne	oui

Authentification : jeton bearer et en-tête d’équipe présentés ci-dessous.

Paramètres

Nom	Emplacement	Requis	Description
`id`	chemin	oui	Identifiant de ressource issu des résultats API de votre équipe.
`X-Tenant-ID`	en-tête	oui	ID de l’équipe active. Doit correspondre au tenant lié au jeton de diagnostic.

Exemple de requête

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

Remplacez YOUR_* du corps avant l’envoi. Le heredoc entre guillemets préserve le JSON littéral.

Réponse : HTTP 200

Flux de travail actualisé

Champs de réponse

Champ	Type	Description
`created_at`	entier	(horodatage Unix)
`data`	objet	État du concepteur de workflows et métadonnées exposées par l’API
`deleted_at`	entier	(horodatage Unix)
`enabled`	booléen
`owner_id`	chaîne
`region`	chaîne
`status`	chaîne	Valeurs autorisées : draft, active, disabled, archived, deleted.
`system_spec`	objet	Spécification canonique du workflow système, synchronisée avec le backend du système
`team_id`	chaîne
`title`	chaîne
`updated_at`	entier	(horodatage Unix)
`workflow_id`	chaîne

Exemple illustratif ; il ne s’agit pas d’une réponse réelle :

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

Supprimer le flux de travail

DELETE /v1/workflow/{id}

Supprime un objet Workflow

Définissez workflow_id en utilisant les ID de vos propres réponses API.

Cette requête modifie des données ou lance une action. Vérifiez la cible et le corps avant de l’envoyer.

Authentification : jeton bearer et en-tête d’équipe présentés ci-dessous.

Paramètres

Nom	Emplacement	Requis	Description
`id`	chemin	oui	Identifiant de ressource issu des résultats API de votre équipe.
`X-Tenant-ID`	en-tête	oui	ID de l’équipe active. Doit correspondre au tenant lié au jeton de diagnostic.

Exemple de requête

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"

Réponse : HTTP 200

Ressource supprimée.

Champs de réponse

Champ	Type	Description
`message`	chaîne

Exemple illustratif ; il ne s’agit pas d’une réponse réelle :

{
  "message": "Deleted successfully"
}

Lister les exécutions de workflow

GET /v1/workflow/{id}/runs

Lister les exécutions du workflow sélectionné.

Définissez workflow_id en utilisant les ID de vos propres réponses API.

Authentification : jeton bearer et en-tête d’équipe présentés ci-dessous.

Paramètres

Nom	Emplacement	Requis	Description
`id`	chemin	oui	Identifiant de ressource issu des résultats API de votre équipe.
`X-Tenant-ID`	en-tête	oui	ID de l’équipe active. Doit correspondre au tenant lié au jeton de diagnostic.

Exemple de requête

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"

Réponse : HTTP 200

Réponse réussie. Inspectez l’état renvoyé pour les opérations qui démarrent un travail asynchrone.

Aucun schéma complet du corps de réponse n’est publié pour cette opération personnalisée. Inspectez le contenu renvoyé et le statut ; aucun format de données n’est présumé ici.

Exécuter le flux de travail

POST /v1/workflow/{id}/runs

Démarrez un workflow configuré. Placez les données d’entrée du workflow dans payload. Cela peut effectuer les actions externes définies par le workflow et nécessite un abonnement payant.

Définissez workflow_id en utilisant les ID de vos propres réponses API.

Cette requête modifie des données ou lance une action. Vérifiez la cible et le corps avant de l’envoyer.

Authentification : jeton bearer et en-tête d’équipe présentés ci-dessous.

Paramètres

Nom	Emplacement	Requis	Description
`id`	chemin	oui	Identifiant de ressource issu des résultats API de votre équipe.
`X-Tenant-ID`	en-tête	oui	ID de l’équipe active. Doit correspondre au tenant lié au jeton de diagnostic.

Exemple de requête

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

Remplacez YOUR_* du corps avant l’envoi. Le heredoc entre guillemets préserve le JSON littéral.

Réponse : HTTP 201

Réponse réussie. Inspectez l’état renvoyé pour les opérations qui démarrent un travail asynchrone.

Aucun schéma complet du corps de réponse n’est publié pour cette opération personnalisée. Inspectez le contenu renvoyé et le statut ; aucun format de données n’est présumé ici.

Obtenir les journaux de flux de travail

GET /v1/workflow/{id}/logs

Lisez les journaux du cycle de vie du workflow.

Définissez workflow_id en utilisant les ID de vos propres réponses API.

Authentification : jeton bearer et en-tête d’équipe présentés ci-dessous.

Paramètres

Nom	Emplacement	Requis	Description
`id`	chemin	oui	Identifiant de ressource issu des résultats API de votre équipe.
`X-Tenant-ID`	en-tête	oui	ID de l’équipe active. Doit correspondre au tenant lié au jeton de diagnostic.

Exemple de requête

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"

Réponse : HTTP 200

Réponse réussie. Inspectez l’état renvoyé pour les opérations qui démarrent un travail asynchrone.

Aucun schéma complet du corps de réponse n’est publié pour cette opération personnalisée. Inspectez le contenu renvoyé et le statut ; aucun format de données n’est présumé ici.