Automatisations

Les automatisations permettent à Tillor d'exécuter lui-même des actions, comme créer des tâches ou appeler votre système. Le mode d'emploi pour les utilisateurs se trouve dans Automatisations. Cette page décrit ce que voit un intégrateur : le message de l'étape Envoyer un webhook, la Requête API vers une URL personnalisée ou vers l'API Tillor, et la structure d'un flux lorsque vous le gérez via l'API.

Envoyer un webhookCopier le lien vers cette section

L'étape Envoyer un webhook livre un message personnalisé à l'un des webhooks de l'organisation. C'est la même livraison que pour les événements de webhook ordinaires, avec la même signature.

Le messageCopier le lien vers cette section

L'étape effectue un POST avec Content-Type: application/json et ces en-têtes :

Le corps a la même enveloppe que la charge utile d'un webhook :

{
  "event": "automation.invoice_unpaid",
  "data": {
    "invoice": "2026-0042",
    "amountOutstanding": 125.5
  },
  "timestamp": 1735689600000,
  "traceId": "0b0f7c0e-5d3c-4c1e-9b8a-7f1e2a3b4c5d",
  "triggeredBy": null
}

Il n'y a pas de spanId. Le webhook n'a pas besoin d'être abonné à une clé d'événement : un message issu d'une automatisation est toujours livré au endpoint choisi, tant qu'il existe et qu'il est activé.

La vérification de la signature est décrite dans Vérifier la signature.

Tentatives et résultatCopier le lien vers cette section

Tillor effectue jusqu'à 5 tentatives dans l'étape, avec 1, 2, 4 et 8 secondes d'attente entre elles. Une tentative est réussie avec un statut 2xx. Une cible bloquée, par exemple une adresse interne, compte aussi comme tentative échouée.

• Si l'une des tentatives réussit, le flux continue par la sortie Réussi
• Si les cinq échouent, le flux continue par Échec. Le message est ensuite encore réessayé en arrière-plan selon le calendrier décrit dans Comportement de livraison et nouvelles tentatives. Si une tentative ultérieure réussit, cela ne se reflète plus dans l'exécution, car celle-ci a déjà continué

Si le webhook n'existe plus ou est désactivé, l'étape ne passe pas par Échec. L'exécution s'arrête alors avec le statut Échec.

Requête API vers une URL personnaliséeCopier le lien vers cette section

Avec Requête API et Envoyer à sur URL personnalisée, une automatisation envoie une requête HTTP vers votre serveur.

Une réponse avec un statut 2xx continue par Réussi, tout autre statut par Échec. Si le serveur est injoignable ou dépasse le délai d'expiration, l'exécution s'arrête avec le statut Échec.

Requête API vers l'API TillorCopier le lien vers cette section

Avec Envoyer à sur Tillor API, l'automatisation appelle l'API de sa propre organisation. Vous indiquez seulement un chemin, par exemple /tasks, et Tillor le place derrière /api/orgs/{orgId}. Votre référence d'API se trouve sur OpenAPI.

• Identité : la requête est exécutée en tant qu'utilisateur Workflow de l'organisation. Celui-ci a toutes les permissions au sein de cette organisation et nulle part ailleurs. Les modifications sont donc enregistrées au nom de Flux de travail
• Pas de clé nécessaire : Tillor effectue l'appel lui-même, sans clé API et sans passer par Internet
• Chemin : doit commencer par un seul /. //, .. et \ ne sont pas autorisés. Une chaîne de requête est permise, par exemple /tasks?terrainId=…&limit=1. Les variables dans le chemin sont insérées encodées
• Bloqué : les chemins /automations et /automation-runs sont refusés, même avec une chaîne de requête, des majuscules, un / final ou un codage en pourcentage. Une automatisation ne peut pas gérer des automatisations
• Corps : JSON, pour POST, PUT et PATCH. Pour GET et DELETE, il n'est pas envoyé
• Menu de choix : dans l'éditeur figure Choisissez un endpoint API avec les opérations de la spécification OpenAPI. Les opérations internes n'y figurent pas. Si vous en choisissez une, Tillor remplit la méthode, le chemin et un exemple de corps
• Échec : une réponse 2xx continue par Réussi. Un statut d'erreur, y compris un 404 pour un chemin inexistant, passe par Échec

La réponse dans les étapes suivantesCopier le lien vers cette section

Après la requête, ces variables sont disponibles :

Une deuxième requête API dans le même flux remplace response. Les variables fonctionnent comme dans Variables et modèles.

La structure d'un fluxCopier le lien vers cette section

Vous pouvez aussi créer et modifier des automatisations via l'API. Les opérations figurent dans OpenAPI sous le tag automations. La lecture requiert la permission automations:read, la création et la modification automations:write (ou toutes les permissions). L'utilisateur Workflow lui-même ne peut jamais les appeler. Il peut être plus pratique de construire un flux dans l'éditeur et de le lire comme exemple.

Une nouvelle automatisation est toujours désactivée. L'activer via enabled échoue tant que le flux a des problèmes ouverts, et vous ne pouvez pas enregistrer un flux activé qui a des problèmes.

La definition se compose d'étapes (nodes), de liens (edges) et, en option, de remarques (notes). Maximum 100 étapes, 200 liens et 50 remarques.

{
  "nodes": [
    {
      "id": "trigger",
      "type": "trigger",
      "label": "",
      "position": { "x": 0, "y": 0 },
      "config": { "source": "event", "eventKey": "occupation:ended" }
    },
    {
      "id": "task",
      "type": "taskCreate",
      "label": "",
      "position": { "x": 0, "y": 190 },
      "config": { "title": "Controleer {occupation.terrain.name}", "priority": "HIGH" }
    }
  ],
  "edges": [
    { "id": "trigger:out:task", "source": "trigger", "target": "task", "sourceHandle": "out" }
  ],
  "notes": [
    {
      "id": "note_1",
      "text": "Maakt na elk vertrek een controletaak.",
      "position": { "x": 340, "y": 0 },
      "width": 240,
      "height": 140
    }
  ]
}

Une remarque (notes) est une explication sur le canevas. Elle n'est jamais exécutée et n'a pas de liens. text fait 2000 caractères maximum, width et height sont en pixels.

Un lien a un sourceHandle : la sortie de l'étape dont il part.

Toute action sauf webhookSend et httpRequest reçoit une sortie supplémentaire error dès que continueOnError est à true dans la config. Sans ce réglage, une action échouée arrête l'exécution. Avec ce réglage, le flux continue par error, avec {error.message} et {error.step} comme variables pour les étapes suivantes. La sortie skipped est utilisée lorsqu'une étape n'avait rien à faire, et out est alors la sortie ordinaire.

Pour forEach, la sortie each démarre une exécution propre par élément pour les étapes suivantes, et la sortie done est la suite ordinaire du flux lui-même.

Une sortie peut mener à plusieurs étapes. L'exécution continue elle-même avec le premier lien et démarre pour chaque autre lien une exécution propre avec les mêmes données, qui tourne en parallèle (comme la sortie each de forEach). Les liens qui forment une boucle sont refusés dans l'éditeur. Un flux a exactement un trigger.

Réglages par étapeCopier le lien vers cette section

Les champs sous config sont les champs de l'éditeur. Les champs de texte acceptent des variables entre accolades.

conditions a la forme { "match": "all" ou "any", "rules": [...] }. Chaque règle est { "id", "field", "operator", "value", "values" }. operator vaut is, isNot, contains, greaterThan, lessThan, isOneOf, isEmpty ou isNotEmpty. Vous n'utilisez values que pour isOneOf. Une liste de règles vide laisse tout passer.

Démarrer une automatisation avec un webhookCopier le lien vers cette section

Une automatisation avec le déclencheur webhook démarre à la suite d'un POST vers sa propre adresse :

curl -X POST "https://tillor.eu/api/orgs/org_abc123/automation-hooks/aut_xxx/<token>?bron=website" \
  -H "Content-Type: application/json" \
  -d '{"email":"jan@voorbeeld.nl","aankomst":"2026-07-14"}'

• L'adresse complète figure dans l'éditeur, au niveau du déclencheur, ou via GET /automations/{id}/webhook-url (avec automations:read). Le jeton est le secret ; un en-tête d'authentification n'est pas nécessaire
• Le corps JSON devient la variable body, la chaîne de requête query, et l'heure receivedAt
• Réponse 200 avec { "accepted": true } dès que l'exécution a démarré. Une adresse erronée, remplacée ou désactivée renvoie 404, un corps de plus de 100 Ko renvoie 400
• De nombreux appels rapprochés ne sont pas refusés : chaque appel valide démarre une exécution. Utilisez Ignorer les répétitions sur le déclencheur si le même appel peut arriver deux fois, voir Ignorer les répétitions

Une automatisation ne peut pas appeler son propre webhook via une Requête API vers l'API Tillor.

Choisir une décision via l'APICopier le lien vers cette section

La tâche d'une étape Demander une décision a une action par option que vous avez définie dans l'étape. Récupérez la tâche pour voir les actions avec leur id, et choisissez-en une avec POST /tasks/{id}/actions/{actionId}/choose. Si l'option demande une note, envoyez-la avec { "note": "..." }. Le choix est définitif : il clôt la tâche et poursuit l'automatisation par la sortie de cette option. Les collègues assignés (y compris via un groupe) et les administrateurs peuvent choisir. Voir OpenAPI pour les détails.

Pour en savoir plusCopier le lien vers cette section

• Webhooks pour la signature, les nouvelles tentatives et la liste des événements
• API HTTP pour l'authentification et le contexte d'organisation
• Variables et modèles pour le mode d'emploi utilisateur