Options de déclenchement

Le body de POST /api/v1/automations/:id/trigger accepte les paramètres suivants. Tous sont optionnels.

Paramètres

Champ	Type	Défaut	Description
sessionId	string	—	ID d'une session navigateur à réutiliser
enableAI	boolean	true	Activer la génération IA de contenu pour les actions compatibles
prompt	string	—	Contexte additionnel pour la génération IA
captureAllSteps	boolean	false	Capturer un screenshot après chaque action
blockAssets	boolean	hérité de l'automation (true)	Bloquer images/CSS/polices (~75% de bande passante proxy économisée). Mettre à false pour charger la page complète (captures fidèles)
values	Record<string, any>	—	Map index d'action → valeur de remplacement
parameters	Record<string, any>	—	Valeurs des paramètres nommés {{param:clé}} utilisés dans les champs/URLs des actions
persistToSession	string[]	—	Clés de parameters à enregistrer (chiffrées) sur la session créée — pour qu'un recovery de sentinelle puisse reconnecter ce compte (voir section)
enableSelfHealing	boolean	false	Réparer en direct une étape cassée et persister le correctif (voir section)

values — Surcharge de valeurs

Le paramètre values permet de remplacer les valeurs des actions au moment de l'exécution. La clé est l'index de l'action (sa position dans la liste, en partant de 0) :

{
  "values": {
    "0": "john@example.com",
    "1": "SecureP@ss123",
    "3": "John Doe"
  }
}

Comment ça fonctionne

Considérons une automation avec ces actions :

Index	Type	Nom	Valeur par défaut
0	fill	Email	default@test.com
1	fill	Password	defaultpwd
2	click	Submit	—
3	fill	Nom complet	Test User

Avec "values": { "0": "john@example.com", "3": "John Doe" } :

• Action 0 → utilise john@example.com au lieu de default@test.com
• Action 1 → garde defaultpwd (pas surchargée)
• Action 2 → pas de valeur (action click)
• Action 3 → utilise John Doe au lieu de Test User

Comportement avec l'IA

Les actions dont la valeur est surchargée via values ne passent pas par la génération IA, même si enableAI est activé. Cela permet de mixer valeurs manuelles et contenu généré.

Index invalides

Les index hors limites ou non numériques sont silencieusement ignorés.

parameters — Paramètres nommés

Contrairement à values (par index), parameters fournit des valeurs par nom, injectées partout où une action référence {{param:clé}} (champ ou URL) :

{
  "parameters": {
    "email": "john@example.com",
    "password": "SecureP@ss123"
  }
}

Une action fill dont la valeur est {{param:email}} recevra john@example.com. Utile pour des automatisations réutilisables où la même structure tourne avec des données différentes.

persistToSession — Enregistrer des identifiants sur la session

Les clés listées dans persistToSession voient leur valeur (prise dans parameters) chiffrée et stockée sur la session produite par le run. Objectif : permettre à un sentinel de reconnecter ce compte en cours d'exécution ultérieure (déconnexion détectée → rejeu du flux de login sur la même session/IP) sans avoir à repasser les identifiants à chaque run.

{
  "parameters": { "email": "john@example.com", "password": "SecureP@ss123" },
  "persistToSession": ["email", "password"]
}

• Typiquement utilisé sur le run de création de compte : il enregistre email/mot de passe (chiffrés) dans la session générée.
• Les valeurs sont chiffrées au repos (AES-256-GCM) et jamais renvoyées par l'API — seules les clés sont exposées (champ secureVarKeys de la session). Requiert SESSION_VARS_SECRET côté serveur ; sans ce secret, rien n'est stocké.
• Lors d'un recovery, les paramètres nécessaires au flux de login (ses {{param:…}}) et absents du run courant sont complétés depuis ces valeurs de session.

sessionId — Réutiliser une session

Passer un sessionId permet de reprendre une session navigateur existante (cookies, localStorage, fingerprint). Utile pour des workflows qui nécessitent d'être connecté :

{
  "sessionId": "665a1b2c3d4e5f6a7b8c9d0e"
}

captureAllSteps — Mode debug

Active la capture de screenshots après chaque action. Les screenshots sont accessibles via l'exécution.

{
  "captureAllSteps": true
}

enableSelfHealing — Réparation d'étape

Quand une action échoue, l'IA tente de réparer l'étape en direct avant d'appliquer la stratégie d'erreur, selon une cascade :

1. observe — relocaliser le sélecteur de l'élément (cas de la dérive de markup : l'élément existe mais son sélecteur a changé).
2. act (sémantique) — si observe ne trouve rien, réaliser l'étape par intention (l'IA trouve l'élément par son sens : n'importe quel texte/position, scroll, vision si disponible). Gère le cas fréquent où l'élément n'existe pas sous ce sélecteur/texte (ex. une bannière qui dit « Continuer sans accepter » au lieu de « Tout accepter »).

{
  "enableSelfHealing": true
}

Persistance : le sélecteur réparé (via observe ou via le sélecteur réellement utilisé par act) est persisté sur l'automation par mise à jour ciblée — donc l'automation se répare durablement et les exécutions suivantes ne rejouent plus l'erreur.

Ce que ça NE répare PAS :

• une URL morte / un navigate qui renvoie 404 ;
• une erreur de logique, de timing, de proxy, de captcha ou de session ;
• une valeur incorrecte ou un flux fondamentalement différent (là, il faut corriger ou régénérer l'automation).

Suivi en direct : pendant une réparation, une encoche apparaît en bas de l'éditeur ; cliquez dessus pour ouvrir la vue live (captures du navigateur piloté par l'IA + outils observe/act). La trace de réparation reste consultable au-dessus des phases après coup.

Exemple complet

curl -X POST https://api.gurren.leandre.io/api/v1/automations/665a.../trigger \
  -H "x-api-key: gfac_votre_cle" \
  -H "Content-Type: application/json" \
  -d '{
    "sessionId": "sess_abc123",
    "enableAI": true,
    "prompt": "Utiliser un ton professionnel",
    "captureAllSteps": false,
    "blockAssets": false,
    "enableSelfHealing": true,
    "values": {
      "0": "john@example.com",
      "1": "MonMotDePasse123"
    }
  }'