A webhook lets Pyron tell another system the moment something happens in it — a high-priority entry logged, a lifecycle action taken — by delivering a signed message to a web address that system controls. You build one from two pieces: a saved connection that holds the receiver's web address and a signing secret, and an automation that sends the message when its trigger fires.
Outgoing webhooks
An outgoing webhook is a step inside an automation. When the automation's trigger fires, the step posts a small JSON message to a web address the receiving system exposes, and that system reacts however it likes — opens a ticket, updates a dashboard, pages someone on call.
Two things have to be in place first:
- A connection to the receiver. A saved outbound connection holds the receiver's base web address and the signing secret that proves each delivery came from you. The message body never carries the secret; it stays on the connection.
- An automation that sends it. An automation with an event trigger decides when a webhook goes out — for example, whenever an entry is logged, optionally narrowed with a condition so it fires only on the deliveries that matter.
To set one up:
- Create an outbound connection for the receiving system, giving it the receiver's base web address and a signing secret. See outbound connections.
- Build an automation and choose the event that should notify the receiver as its trigger.
- Add the step that sends the webhook. Point it at the connection, give the receiver's web address, and compose the message as a set of fields. Values in the message can be filled from the triggering event using placeholders.
- Turn the automation on. Each matching event then delivers one message.
Because a webhook is an ordinary automation, every delivery appears in the automation's run history — when it went out, whether it succeeded, and the response it got back. To notify several receivers, or to work through a list of entries, the automation loops and sends a message for each.
A webhook sends information out of Pyron to another system. For the reverse direction — letting an external system call into Pyron when something happens on their side — see inbound API keys.
Signing and retries
How each delivery is signed
Every delivery is signed so the receiver can confirm it came from Pyron and arrived unaltered. Pyron computes an HMAC-SHA256 signature over the delivery's timestamp and the exact message body, using the signing secret stored on the connection, and sends both alongside the message:
X-Timestamp: 1721452800
X-Signature: sha256=<hex digest>On the receiving end, the system recomputes the signature from the same timestamp and the raw body using its own copy of the secret. A delivery whose signature does not match — because the body was altered in transit, or because it is a stale replay — is rejected. If a connection has no signing secret stored, the sending step fails before anything goes out, so a webhook is only ever delivered signed.
Have the receiving system check the signature on every request before acting on the body, and reject anything that fails. The signing secret is the whole basis of trust — treat it like a password and keep it off the message body.
Retries and duplicate deliveries
A delivery can fail for reasons that clear on their own — the receiver is briefly unreachable, the request times out, or the receiver returns a busy or server error. The automation engine retries these transient failures rather than giving up on the first miss. How many times a failed delivery is reattempted is part of the sending step's settings.
A retry re-sends the same message. The signature's timestamp is fixed on the first attempt and reused on every retry, so a retried delivery carries an identical signature to the original. That lets the receiver recognise a repeat and act on it once — deduplicate on the timestamp and signature — rather than process the same event twice. Design the receiver so that handling the same delivery again does no harm.
Each attempt and its outcome is kept in the automation's run history, so a delivery that failed and its retries are there to inspect. For the signature format and the other details needed to build the receiving end, see the API and webhooks reference.