Un déclencheur, appelé comme ça t'arrange.
Un déclencheur, c'est un événement customque tu définis toi-même — « commande reçue », « dossier approuvé », « paiement externe », ce que ta business génère. Une fois créé, tu l'appelles de la façon qui fait ton affaire : par webhook depuis un système externe, sur un horaire, ou en lot. C'est ton bus d'événements à toi, dans ton CRM, au lieu d'un service tiers à brancher.
Signé, et à toi en deux minutes.
Chaque déclencheur vient avec un guide d'intégration: des bouts de code prêts à copier (cURL, Node, Python, PHP, lot) avec ton vrai secret dedans, fait qu'un développeur le branche en quelques minutes au lieu de fouiller une doc générique. C'est conçu pour qu'une intégration soit sûre par défaut, pas après coup.
const res = await fetch(
"https://api.toncrm.io/triggers/commande-recue",
{
method: "POST",
headers: {
"X-Signature": sign(body, SECRET),
"Idempotency-Key": orderId,
},
body: JSON.stringify({ montant: 1290, devise: "CAD" }),
}
);Ça plante ? Ça se retente tout seul.
Si un dispatch échoue — le système de l'autre bord est down, une erreur réseau — toncrm le re-tente automatiquement, en espaçant les essais, jusqu'à cinq fois. Toujours rien ? L'événement tombe dans une file morte pis un courriel part au propriétaire. Rien se perd en silence.
Pis la file morte, c'est une vraie interface où tu peux re-déclencher ou jeterchaque événement, un par un. Le moteur garantit qu'un même événement se déclenche jamais en double, même avec plusieurs traitements en parallèle. Les pannes temporaires se règlent toutes seules, pis les vraies erreurs finissent dans un seul endroit clair au lieu de disparaître dans le néant.
Tu peux retenter sans dupliquer.
Quand t'intègres deux systèmes, le même appel finit parfois par partir deux fois — un timeout de ton bord, un retry, un doigt nerveux. toncrm gère ça avec une clé d'idempotence : si le même événement arrive deux fois, il rejoue la réponse d'origine au lieu de le traiter une deuxième fois. Tu retentes un appel sans risquer de créer un doublon ni de déclencher deux fois la même chose.
C'est le genre de détail qui fait la différence entre une intégration qui tient pis une qui te crée des bogues fantômes — la garantie qui transforme un système nerveux en un système sur lequel on bâtit pour de vrai.
Des conditions et une validation.
Un déclencheur, c'est pas un tuyau qui avale n'importe quoi. Tu peux poser des conditionssur le contenu de l'événement (continue seulement si le montant dépasse 1000) pis remapperles données avant qu'elles servent.
Pis chaque événement est validé contre un schéma typé — texte, nombre, courriel, date, et ainsi de suite — avec des erreurs claires qui te disent exactement quel champ cloche pis ce qui était attendu. Tu décides ce qui mérite de continuer, pis les données qui entrent sont propres avant même de toucher au reste de ton système.
Chaque déclenchement sait d'où il vient.
Un même déclencheur peut partir de plusieurs façons — pis chacune est tracée à sa sourcedans le journal d'exécution. Un webhook externe, un horaire, un envoi en lot, un rejeu manuel, un test depuis l'interface, la chaîne d'un workflow ou une commande à l'assistant : tu sais toujours pourquoiun événement a roulé, pas juste qu'il a roulé.
Côté routage, tes conditions vont plus loin qu'un simple « égal à » : neuf opérateurs (égal, différent, plus grand, contient, commence par…) pis un remappage du contenu avant la condition. Pis un déclencheur peut chaîner vers un workflow— l'événement entre, l'automatisation prend le relais.
Rejoue n'importe quel événement — avec sa version d'origine.
Tu peux rejouern'importe quel événement passé depuis l'interface. Pis voici le bout intelligent : si t'as changé le schéma de l'événement depuis, le rejeu utilise le schéma qu'il avait à l'époque, pas le schéma courant. Autrement dit, un rejeu reproduit vraimentce qui s'est passé, au lieu de planter contre une version plus récente.
Tes événements gardent leur historique de schéma — un détail que la plupart des outils oublient, pis qui te sauve des heures de débogage le jour où tu dois comprendre ce qui s'est passé il y a trois semaines.
Cent événements en un seul appel.
Pour importer ou synchroniser en masse, tu peux envoyer jusqu'à cent événements en un seul appel, avec une gestion du succès partiel: tu sais exactement lesquels sont passés pis lesquels ont accroché, au lieu d'un tout-ou-rien. Pratique quand tu branches un système qui crache beaucoup de données d'un coup.
Le bus d'événements, en bref.
Tout sur les déclencheurs.
Branche ton premier déclencheur.
14 jours gratuits, aucune carte. Ou réserve une démo, on branche ton premier webhook avec toi.
On branche ton premier webhook avec toi en démo.
