Démarre le workflow quand une requête HTTP atteint l'URL publique (affichée ci-dessus une fois publié).
Utilisation et spécificités
Publiez le workflow pour obtenir l’URL active. Respectez la méthode HTTP et l’authentification configurées. La réponse peut être immédiate, issue d’un nœud ou diffusée en streaming selon le mode.
Type technique : webhook. Runtime : nodulz.
Exemple guidé
Pour recevoir une demande contenant une adresse e-mail :
Ajoutez ce déclencheur et choisissez la méthode POST avec un chemin unique, par exemple /demo-request.
Dans Payload de test, saisissez { "email": "[email protected]", "amount": 120 }.
Reliez un nœud Modifier les champs, activez Champs mappés uniquement et ajoutez email avec {{ input.body.email }} et amount avec {{ input.body.amount }}.
Exécutez depuis l’éditeur. La sortie de préparation doit contenir l’adresse et le nombre 120.
Pour simuler aussi la query et les en-têtes, utilisez une enveloppe de requête complète :
Lisez alors {{ input.query.source }} pour obtenir demo. Un objet de test simple est placé dans input.body ; un objet contenant des clés d’enveloppe comme body, headers ou query est interprété comme une requête complète. Utilisez l’enveloppe explicite si vos données métier portent elles-mêmes ces noms.
Après le test de traitement, configurez l’authentification requise, publiez et copiez l’URL affichée par le nœud. Depuis votre appelant, envoyez le même corps JSON avec la méthode POST, Content-Type: application/json et les éléments d’authentification choisis. Ne reconstruisez pas l’URL depuis l’adresse de l’éditeur.
En mode de réponse immédiate, la réponse à l’appelant ne contient pas nécessairement le résultat final. Si le client doit recevoir un résultat calculé, utilisez un mode qui attend ce résultat, par exemple un nœud Réponse webhook configuré et sélectionné comme réponse.
Identifiants et prérequis
Aucun identifiant externe dédié n’est défini par ce nœud. Les sources distantes ou la cible d’exécution peuvent néanmoins nécessiter leurs propres accès.
Consultez le guide des identifiants si une source distante ou une cible d’exécution nécessite un accès.
Paramètres
Les noms ci-dessous correspondent aux clés techniques. Les valeurs par défaut ne constituent pas une configuration prête à exécuter : renseignez les champs requis par votre opération. Les chemins contenant [] décrivent les éléments d’une liste ; certains champs dépendent du mode sélectionné.
Verbe HTTP utilisé pour l'appel (GET, POST, PUT, PATCH, DELETE).
path Chemin
Chemin ajouté après /api/hooks (ex. /orders → …/api/hooks/orders). Unique par déclencheur.
multipart Fichiers
Accepte un corps multipart/form-data. Jusqu’à 50 fichiers (25 Mo chacun, 64 Mo au total), exposés dans input.files (nom, type MIME, base64). Les champs texte restent dans body. Republiez le workflow après activation.
authentication Authentification
Vérification avant toute capture ou exécution. Republiez le workflow après modification. Les identifiants reçus sont retirés des données transmises au workflow.
authUsername Identifiant Basic
Identifiant attendu, sans deux-points. Le champ secret contient le mot de passe. Envoi via Authorization: Basic base64(identifiant:mot de passe).
jwtAlgorithm Algorithme JWT
HS256 utilise le secret partagé ; RS256 utilise une clé publique PEM. Jeton Bearer avec exp obligatoire ; nbf est vérifié si présent. Aucun autre algorithme accepté.
jwtPublicKey Clé publique JWT
Clé publique SPKI au format PEM (BEGIN PUBLIC KEY). Ne collez pas de clé privée.
jwtIssuer Émetteur JWT (optionnel)
Si renseigné, exige une correspondance exacte du claim iss.
jwtAudience Audience JWT (optionnelle)
Si renseignée, exige cette audience dans le claim aud.
signatureHeader En-tête de signature
Nom de l’en-tête reçu. Vide : x-signature pour HMAC, stripe-signature pour Stripe. Insensible à la casse.
signatureEncoding Encodage de la signature
HMAC-SHA256 du corps brut, encodé en hex ou base64. Préfixe sha256= facultatif. Aucune protection contre le rejeu dans ce mode ; utilisez Stripe pour une signature horodatée.
testPayload Payload de test
JSON utilisé lors des exécutions de test dans l'éditeur (bouton Exécuter). Simule le corps, les en-têtes et la query du webhook. Objet simple = input.body. Objet complet avec body, headers, query, method pour simuler toute la requête.
respond Répondre
Quand renvoyer la réponse HTTP à l'appelant.
respondNodeKey Nœud en streaming
Ouvre la réponse HTTP au démarrage du workflow et envoie le texte de ce nœud au fil de sa production (souvent un nœud IA). Content-Type : text/plain.
responseTemplate Modèle de réponse
JSON avec expressions JavaScript : {{ Object.keys(input.body) }}, {{ nodes.http1.body.data.length }}, {{ nodes.set1.api_items[0].id }}, etc. Chaque valeur entre {{ … }} est résolue depuis input, nodes.http1, nodes.set1 ou vars.
respondNodeKey Nœud de réponse
Choisissez un nœud Réponse webhook en aval. Son modèle JSON sera renvoyé au client.
respondNodeKey Nœud de réponse
Renvoie la sortie brute de ce nœud.
Exemples
Chemin : /orders-created
Payload disponible dans input.body, input.headers, input.query
Auth : x-nodulz-secret: votre-secret
Réponse : modèle JSON combinant input.body et nodes.http1.body.data
Configuration initiale
Exemple de configuration initiale du catalogue, à adapter avant exécution. Les secrets doivent rester dans les identifiants.
Vérifiez d’abord le payload simulé, puis effectuez une vraie requête vers l’URL publiée. Retrouvez l’exécution et contrôlez son entrée et son statut final. Si aucune exécution n’apparaît, vérifiez méthode, URL, authentification et accès réseau. Republiez après un changement du déclencheur. Un test simulé ne valide pas ces contrôles entrants.
Démarre le workflow quand une requête HTTP atteint l'URL publique (affichée ci-dessus une fois publié).
Utilisation et spécificités
Publiez le workflow pour obtenir l’URL active. Respectez la méthode HTTP et l’authentification configurées. La réponse peut être immédiate, issue d’un nœud ou diffusée en streaming selon le mode.
Type technique :
webhook. Runtime :nodulz.Exemple guidé
Pour recevoir une demande contenant une adresse e-mail :
/demo-request.{ "email": "[email protected]", "amount": 120 }.emailavec{{ input.body.email }}etamountavec{{ input.body.amount }}.Pour simuler aussi la query et les en-têtes, utilisez une enveloppe de requête complète :
{ "method": "POST", "headers": { "content-type": "application/json" }, "query": { "source": "demo" }, "body": { "email": "[email protected]", "amount": 120 } }Lisez alors
{{ input.query.source }}pour obtenirdemo. Un objet de test simple est placé dansinput.body; un objet contenant des clés d’enveloppe commebody,headersouqueryest interprété comme une requête complète. Utilisez l’enveloppe explicite si vos données métier portent elles-mêmes ces noms.Après le test de traitement, configurez l’authentification requise, publiez et copiez l’URL affichée par le nœud. Depuis votre appelant, envoyez le même corps JSON avec la méthode POST,
Content-Type: application/jsonet les éléments d’authentification choisis. Ne reconstruisez pas l’URL depuis l’adresse de l’éditeur.En mode de réponse immédiate, la réponse à l’appelant ne contient pas nécessairement le résultat final. Si le client doit recevoir un résultat calculé, utilisez un mode qui attend ce résultat, par exemple un nœud Réponse webhook configuré et sélectionné comme réponse.
Identifiants et prérequis
Aucun identifiant externe dédié n’est défini par ce nœud. Les sources distantes ou la cible d’exécution peuvent néanmoins nécessiter leurs propres accès.
Consultez le guide des identifiants si une source distante ou une cible d’exécution nécessite un accès.
Paramètres
Les noms ci-dessous correspondent aux clés techniques. Les valeurs par défaut ne constituent pas une configuration prête à exécuter : renseignez les champs requis par votre opération. Les chemins contenant [] décrivent les éléments d’une liste ; certains champs dépendent du mode sélectionné.
rateLimitEnabledbooleanrateLimitMaxnumberrateLimitWindowMsnumberallowedIpsarrayblockedIpsarraymethodenum"POST"GET,POST,PUT,PATCH,DELETEpathstring""authenticationenum"none"none,header,query,basic,bearer,jwt,hmac,stripeauthUsernamestring""jwtAlgorithmenum"HS256"HS256,RS256jwtPublicKeystring""jwtIssuerstring""jwtAudiencestring""signatureHeaderstring""signatureEncodingenum"hex"hex,base64respondenum"immediately"immediately,when_finished,streaming,when_last_node_finishes,when_node_finishes,with_templateresponseFormatenum"response_node"template,last_node,node_output,response_node,streamingresponseTemplatestring"{\n \"data\": \"{{ nodes.http1.body.data }}\",\n \"request\": \"{{ input.body }}\"\n}"respondNodeKeystringsecretstringtestPayloadstring""multipartbooleanfalseAide de configuration
methodMéthode HTTP
pathChemin
multipartFichiers
authenticationAuthentification
authUsernameIdentifiant Basic
jwtAlgorithmAlgorithme JWT
jwtPublicKeyClé publique JWT
jwtIssuerÉmetteur JWT (optionnel)
jwtAudienceAudience JWT (optionnelle)
signatureHeaderEn-tête de signature
signatureEncodingEncodage de la signature
testPayloadPayload de test
respondRépondre
respondNodeKeyNœud en streaming
responseTemplateModèle de réponse
respondNodeKeyNœud de réponse
respondNodeKeyNœud de réponse
Exemples
Configuration initiale
Exemple de configuration initiale du catalogue, à adapter avant exécution. Les secrets doivent rester dans les identifiants.
{ "method": "POST", "path": "", "authentication": "none", "respond": "immediately", "responseFormat": "response_node", "responseTemplate": "{\n \"data\": \"{{ nodes.http1.body.data }}\",\n \"request\": \"{{ input.body }}\"\n}" }Vérification
Vérifiez d’abord le payload simulé, puis effectuez une vraie requête vers l’URL publiée. Retrouvez l’exécution et contrôlez son entrée et son statut final. Si aucune exécution n’apparaît, vérifiez méthode, URL, authentification et accès réseau. Republiez après un changement du déclencheur. Un test simulé ne valide pas ces contrôles entrants.
Voir aussi : Expressions et données, Exécutions, Catalogue des nœuds.