Tout ce qu'il faut pour définir, versionner et exécuter des pipelines IA multi-étapes. JSON natif, API REST, zéro dépendance fournisseur.
Un fichier Waiflo est un document JSON avec trois clés de premier niveau. Il est conçu pour être versionné sous Git, relu en pull request et déployé comme n'importe quel artefact.
{ "lang_name": "my_pipeline", // identifiant unique du pipeline "steps": [ ... ], // définitions d'étapes réutilisables "workflows": [ ... ] // DAGs reliant les étapes entre elles }
| Champ | Type | Description |
|---|---|---|
| lang_name | string | Nom unique du pipeline. Utilisé comme nom de fichier sur le disque. required |
| steps | Step[] | Tableau de définitions d'étapes. Chaque étape est une unité atomique et réutilisable. required |
| workflows | Workflow[] | Tableau de définitions de workflows (DAGs). Chaque workflow relie des étapes en un graphe d'exécution. optional |
Une étape est l'unité atomique d'un pipeline. Elle possède un type, des schémas I/O typés et sa configuration complète dans un seul objet — aucun état caché, aucune héritage implicite.
| Champ | Type | Description |
|---|---|---|
| ws_name | string | Identifiant unique dans le fichier. Utilisé pour référencer l'étape dans les workflows. required |
| ws_type | string | L'un des types : prompt · api · transform · tool · script required |
| ws_inputs_schema | JSONSchema | Objet JSON Schema décrivant les entrées attendues. optional |
| ws_output_schema | JSONSchema | Objet JSON Schema décrivant la sortie attendue. optional |
L'objet ws_llm configure le modèle à appeler. ws_prompt_template supporte la syntaxe Mustache : {{{var}}} pour l'injection brute et {{var}} pour l'échappement HTML.
| Champ | Type | Description |
|---|---|---|
| ws_llm.provider | string | Fournisseur LLM. Actuellement : anthropic. |
| ws_llm.model | string | ID du modèle, ex : claude-sonnet-4-20250514. |
| ws_llm.temperature | number | 0–1. Défaut : 0. optional |
| ws_system_prompt | string | Chaîne de prompt système. Injectée avant le tour utilisateur. |
| ws_prompt_template | string | Template du tour utilisateur. Supporte {{input_var}} et {{ws_output_schema}}. |
{ "ws_name": "classify", "ws_type": "prompt", "ws_llm": { "provider": "anthropic", "model": "claude-sonnet-4-20250514", "temperature": 0 }, "ws_system_prompt": "You are a classifier. Reply with JSON only.", "ws_prompt_template": "Classify: \nSchema: ", "ws_inputs_schema": { "required": ["input_text"] }, "ws_output_schema": { "properties": { "label": { "type": "string" } } } }
Les templates d'URL et de corps supportent la substitution {{input_var}} résolue depuis les inputs à l'exécution.
| Champ | Type | Description |
|---|---|---|
| ws_api.method | string | Méthode HTTP : GET · POST · PUT · PATCH · DELETE. |
| ws_api.url | string | URL. Supporte la substitution de template {{input_var}}. |
| ws_api.headers | object | Objet d'en-têtes statiques ou templatisés. optional |
| ws_api.body | object | Corps de la requête. Objet ou chaîne. optional |
Un workflow est un graphe acyclique orienté (DAG) de références d'étapes. Le moteur déduit l'ordre d'exécution depuis les déclarations depends_on.
| Champ | Type | Description |
|---|---|---|
| wf_name | string | Nom unique du workflow. required |
| wf_nodes | Node[] | Tableau ordonné de nœuds, chacun référençant une étape via step_id. required |
| Champ | Type | Description |
|---|---|---|
| step_id | string | Référence un ws_name déclaré dans le tableau steps. |
| depends_on | string[] | Tableau de step_id qui doivent se terminer avant que ce nœud s'exécute. Les données transmises proviennent explicitement des champs de ws_output_schema (pas d'alias implicites). optional |
{ "wf_name": "triage_and_respond", "wf_nodes": [ { "step_id": "classify_ticket" }, { "step_id": "enrich_customer", "depends_on": ["classify_ticket"] }, { "step_id": "draft_response", "depends_on": ["classify_ticket", "enrich_customer"] } ] }
Téléchargez le schéma OpenAPI YAML complet de l'API Waiflo pour l'importer dans Postman, Insomnia ou votre outillage interne.
GET /json_schemas/waiflo_api.openapi.yaml
L'API exec exécute une étape unique avec les inputs fournis. Aucun compte requis pour un usage invité si ANTHROPIC_API_KEY est défini côté serveur. Les utilisateurs authentifiés apportent leur propre clé chiffrée.
// Corps de la requête { "step": { ... }, // objet de définition d'étape complet "inputs": { ... } // map clé-valeur des inputs } // Réponse // étape prompt → flux SSE data: {"type":"delta","text":"..."} data: {"type":"final","output":{"label":"billing"}} // étape api → JSON { "output": { "status": 200, "body": { ... } } }
Authentification JWT. Les tokens sont valides 7 jours. Passer le token dans l'en-tête Authorization pour tous les endpoints authentifiés.
{ "email": "you@example.com", "password": "min8chars" } // → { "token": "eyJ..." }
{ "email": "you@example.com", "password": "..." } // → { "token": "eyJ..." }
Inclure le token JWT dans toutes les requêtes nécessitant une authentification.
Authorization: Bearer <token>
Endpoints CRUD pour gérer les fichiers de workflow sur le serveur. Les endpoints PATCH utilisent un deep merge récursif — seuls les champs envoyés sont mis à jour. Conçu pour l'autosave et les éditeurs assistés par IA.
{ "workflow_name": "triage", "ws_name": "classify", "patch": { "ws_llm": { "temperature": 0.4 } } }
Seul ws_llm.temperature est modifié. ws_llm.provider et ws_llm.model sont préservés automatiquement.
Auto-hébergé avec Docker. Zéro service externe — juste un secret JWT et votre clé Anthropic.