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.
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?
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.
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?
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.
Where do I see suppressed ones for alarm notifications? We don’t send those from a flow.
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.
- You must be logged in to reply to this topic.
Join the conversation
Sign in to ask and answer, like helpful posts and mark the reply that solved your problem. Every contribution earns points and levels.