2.1.1 pour l'automatisation : secrets nommés dans les requêtes HTTP, déclencheurs webhook durables, rapports de livraison
Traduit de English par IA ·
Trois changements dans la version 2.1.1 pour les personnes qui créent des flux.Secrets par nom dans les champs de requête HTTP. Un champ de requête HTTP peut désormais faire référence à un secret par son nom, et la valeur est renseignée côté serveur. L’adresse et l’authentification d’un appel proviennent toujours de sa connexion de point de terminaison, voir Connexions et secrets.Déclencheurs webhook durables. Les déclencheurs webhook sont désormais stockés de manière durable et réparés automatiquement après une panne.Rapports de livraison pour les notifications. Les notifications signalent désormais les livraisons supprimées ou en échec, afin que vous voyiez ce qui n’est pas parti au lieu de deviner à partir de la boîte de réception. Dans un flux, le résultat du bloc Notify contient les compteurs (livrées, en échec, supprimées et les autres) ; pour les livraisons par e-mail, SMS, push et chat, il existe le journal des notifications.
Three changes in 2.1.1 for people who build flows.
Secrets by name in HTTP request fields. An HTTP request field can now refer to a secret by its name, and the value is filled in on the server. The address and the authentication of a call still come from its endpoint connection, see Connections and secrets.
Durable webhook triggers. Webhook triggers are now stored durably and repaired automatically after an outage.
Delivery reports for notifications. Notifications now report the deliveries that were suppressed or failed, so you can see what did not go out instead of guessing from the inbox. In a flow, the Notify block’s result carries the counts (delivered, failed, suppressed and the rest); for mail, SMS, push and chat deliveries there is the notification log.
Traduit de English par IA ·
Nous avons un flux qui envoie des données à une API fournisseur, avec la clé dans une ligne d’en-tête personnalisée (X-Api-Key). Faut-il la déplacer vers le nouveau secret nommé, ou ailleurs ?
We have a flow that posts to a supplier API with the key in a custom header row (X-Api-Key). Should that move to the new named secret, or somewhere else?
Traduit de English par IA ·
Pour une clé fixe dans un en-tête, je la mettrais sur la connexion de l’endpoint HTTP : type d’authentification header, header_name X-Api-Key, et la valeur va dans header_value, qui est enregistrée comme secret. Ainsi, le bloc ne fait que désigner la connexion, et la ligne correspondante dans les en-têtes du bloc peut être supprimée.Après enregistrement, le champ affiche « Une valeur est enregistrée. Laissez vide pour la conserver. » et la valeur n’apparaît jamais dans un historique d’exécution, un journal ou un export. Si vous exportez le flux plus tard, l’importateur devra saisir à nouveau le secret.
For a fixed key in a header I’d put it on the HTTP endpoint connection: auth type header, header_name X-Api-Key, and the value goes in header_value, which is stored as a secret. Then the block only names the connection and the row in the block’s headers can go.
After saving, the field shows « A value is stored. Leave empty to keep it. » and the value never reaches a run record, a log or an export. If you export the flow later, the importer has to type the secret again.
Traduit de English par IA ·
Une question sur la partie webhook. « Réparé après une panne » signifie-t-il que les appels reçus pendant la panne sont exécutés ensuite, ou seulement que le déclencheur redémarre automatiquement ?
Question on the webhook part. Does « repaired after an outage » mean the calls that came in during the outage get run afterwards, or only that the trigger comes back by itself?
Traduit de English par IA ·
La ligne du changelog concerne le déclencheur lui-même : il est stocké de manière durable et réparé automatiquement après une panne.Pour les appels eux-mêmes, un appel webhook qui a attendu plus longtemps que son time-to-live pendant une panne n’est pas exécuté seul. Il est placé dans Messages en échec avec la raison « Attente trop longue », et Rejouer l’exécute. Rejouer conserve les identifiants d’origine, et les blocs sortants envoient la même clé d’idempotence ; si le système appelé la dédoublonne, il ne voit l’appel qu’une fois. Détails dans Protections et messages en échec.
The changelog line is about the trigger itself: it’s stored durably and repaired automatically after an outage.
For the calls themselves, a webhook call that waited longer than its time-to-live during an outage isn’t run on its own. It goes to Failed messages with the reason « Waited too long », and Replay runs it. Replay keeps the original ids, and the outbound blocks send the same idempotency key, so if the system you call deduplicates it sees the call once. Details in Protections and failed messages.
Traduit de English par IA ·
Où puis-je voir les notifications d’alarme supprimées ? Nous ne les envoyons pas depuis un flow.
Where do I see suppressed ones for alarm notifications? We don’t send those from a flow.
Traduit de English par IA ·
Sur la chronologie de l’alarme. Elle affiche Notifiée avec le nombre de destinataires et de canaux, « Notification retenue » lorsque la limitation en a retenu une, et Mise en sourdine lorsque personne n’a été prévenu.Le journal des notifications ne contient que les tentatives effectuées (envoyée, échouée ou en attente par destinataire et par canal). Une notification retenue avant d’être tentée (par une préférence, les heures calmes, la fenêtre de répétition ou une mise en sourdine) n’a jamais atteint cette étape ; elle n’apparaît donc pas dans le journal, et ces décisions sont affichées sur la chronologie de l’alarme.
On the alarm’s timeline. It shows Notified with the number of recipients and channels, « Notification held back » when the throttle kept one back, and Muted when nobody was told.
The notification log only has attempts that were made (sent, failed or pending per recipient and channel). Something held back before it was attempted (by a preference, quiet hours, the repeat window or a mute) never got that far, so it is not in the log; those decisions show on the alarm timeline instead.
- Vous devez être connecté pour répondre à ce sujet.
Rejoignez la discussion
Connectez-vous pour poser et répondre à des questions, aimer les messages utiles et marquer la réponse qui a résolu votre problème. Chaque contribution rapporte des points et des niveaux.

