Déclencheurs

Les 6 types de déclencheurs disponibles — Manuel, Planifié, Webhook, Projet, Compte rendu, Formulaire.

Le déclencheur est le point de départ d'une automatisation. Six types sont disponibles — choisissez celui qui correspond à la manière dont vous voulez lancer l'exécution.

Configuration d'un déclencheur depuis le panneau latéral

Changer de type de déclencheur

Dans l'éditeur, cliquez sur le nœud de déclencheur (premier nœud du graphe).

Le panneau de configuration s'ouvre à droite.

Dans le champ « Type de déclencheur » (libellé Type de declencheur), sélectionnez le type voulu.

Les options spécifiques au type apparaissent en dessous.

Les 6 types

Manuel

Le plus simple : l'automatisation se lance uniquement à la demande depuis l'éditeur (bouton Exécuter) ou via une API. Idéal pour :

Tester une automatisation en construction.
Lancer ponctuellement une tâche depuis l'interface.

Aucune configuration spécifique.

Planifié

Exécution récurrente selon un cron. Le panneau attend :

Expression cron — par exemple 0 9 * * * (placeholder « tous les jours à 9h »).
Fuseau horaire — par défaut le fuseau de l'instance.

Utile pour : rapports quotidiens, synchronisations périodiques, veille.

Webhook

L'automatisation se lance quand un système externe envoie une requête HTTP à une URL dédiée. Le panneau affiche :

URL du webhook — générée par le système, bouton Copier.
Schéma de requête (optionnel) — décrivez la structure attendue du payload JSON entrant.
Requête de test (optionnel) — un exemple de payload pour les tests.

Si vous venez de créer l'automatisation, l'URL n'est pas encore disponible. Sauvegardez l'automatisation pour générer l'URL — le message « Sauvegardez l'automatisation pour générer l'URL du webhook » s'affiche tant que c'est requis.

Signature et sécurité

Chaque requête entrante doit être signée avec le secret du webhook. Le secret est généré à la création et visible une seule fois dans l'interface — stockez-le côté appelant.

Algorithme : HMAC-SHA256 sur la chaîne ${timestamp}.${rawBody}, encodé en hexadécimal. Deux headers obligatoires :

Header	Format	Notes
`X-Webhook-Timestamp`	Unix timestamp en secondes	Fenêtre acceptée : ±5 min (au-delà, 401)
`X-Webhook-Signature`	`sha256=<hmac_hex>`	Préfixe `sha256=` obligatoire

Codes de réponse : 200 succès, 401 signature/timestamp invalide, 404 secret_id inconnu, 429 rate-limit, 503 workflow désactivé.

Exemple — Node.js / TypeScript

import { createHmac } from "node:crypto"

function signPayload(rawBody: string, secret: string) {
  const ts = Math.floor(Date.now() / 1000).toString()
  const sig = createHmac("sha256", secret).update(`${ts}.${rawBody}`).digest("hex")
  return {
    "X-Webhook-Timestamp": ts,
    "X-Webhook-Signature": `sha256=${sig}`,
  }
}

const body = JSON.stringify({ leadId: "12345" })
await fetch("https://api.superfasttt.ai/api/v1/webhooks/<workflow_id>", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    ...signPayload(body, process.env.WEBHOOK_SECRET!),
  },
  body,
})

Exemple — Python

import hmac, hashlib, time, json, requests

def sign(raw_body: str, secret: str) -> dict[str, str]:
    ts = str(int(time.time()))
    sig = hmac.new(secret.encode(), f"{ts}.{raw_body}".encode(), hashlib.sha256).hexdigest()
    return {"X-Webhook-Timestamp": ts, "X-Webhook-Signature": f"sha256={sig}"}

body = json.dumps({"leadId": "12345"})
requests.post(
    "https://api.superfasttt.ai/api/v1/webhooks/<workflow_id>",
    headers={"Content-Type": "application/json", **sign(body, WEBHOOK_SECRET)},
    data=body,
)

Signez le raw body envoyé sur le fil, pas un objet re-sérialisé. Une différence d'espace ou d'ordre de clés JSON change le HMAC et fait échouer la vérification côté Superfasttt.

Projet

L'automatisation se lance depuis une action sur un projet. Le panneau demande :

Projet — sélectionner un projet précis, ou choisir « Choisir au lancement » pour le demander à l'utilisateur au moment de l'exécution.

Utile pour : automatisations spécifiques à un projet (mise à jour de documents, envoi de livrables…).

Compte rendu

L'automatisation se lance à l'import d'une réunion. Les imports peuvent provenir de plusieurs canaux :

L'app web Comptes-rendus (dépôt manuel d'un fichier).
Les applications mobiles iOS et Android.
Les applications desktop Mac et Windows.

Depuis ces apps mobiles/desktop, l'utilisateur choisit à l'envoi l'automatisation cible parmi celles à trigger « Compte rendu » de son instance — c'est ainsi qu'un enregistrement est routé vers la bonne automatisation (génération de CR, extraction d'actions, envoi par mail…).

Le panneau de configuration permet de paramétrer :

L'audio de test (placeholder « MP3, MP4, WAV ») — pour tester l'automatisation sans attendre une vraie réunion.
Le provider et le modèle de transcription à utiliser.

Limites observées : 5 Mo maximum pour le fichier audio de test (message « Le fichier audio est trop volumineux (max 5MB) » en cas de dépassement). Cette limite ne s'applique qu'au test depuis l'éditeur — les vrais enregistrements transitent par les apps mobile/desktop/web et suivent les limites d'upload de Comptes-rendus.

Formulaire

L'automatisation est exposé comme un formulaire dans Formulaires. Le panneau permet de définir les champs du formulaire (texte, nombre, sélecteur, fichier, etc.) via un constructeur dédié.

C'est le moyen privilégié pour exposer une automatisation à des utilisateurs non techniques.

Et ensuite ?

Actions — paramétrer ce qui s'exécute après le déclencheur.
Variables et templates — passer des données du déclencheur aux étapes suivantes.

On this page