Webhook

A webhook is a notification that one system sends by itself, as an HTTP request to another system’s address, when an event occurs, such as an order being paid.

Also called: HTTP callback

Filip Kostecki

Published 26 August 2026

With webhooks, a company’s systems react to each other straight away: a paid order sends out the files, a new request creates a task, and nobody has to check dashboards every hour. A badly built webhook, however, loses events or lets through fake notifications from someone posing as the sender.

How does it work?

The receiver (your system) exposes a public HTTPS address and registers it with the sender, choosing the events it wants to hear about. Both sides share a secret used to sign the messages.
When the event occurs, the sender makes an HTTP POST request to that address, with the data in JSON. Stripe and GitHub also attach a signature calculated from the message and the secret.
The receiver checks the signature and the age of the message, then the event ID: if it has already handled that event, it skips the repeat.
The receiver replies with a 2xx code at once and does the longer work in the background, because GitHub waits 10 seconds for a reply and Microsoft Graph only 3.
If no reply comes, the sender retries the delivery or drops it, depending on the service.

Example from practice

On fkdrive.com we sell our playbook, a guide in Polish, through Stripe. When a payment goes through, Stripe sends a webhook to our server, and the server sends the buyer the files by itself. Before sending, the server checks the signature and rejects messages older than 5 minutes, in line with Stripe’s default setting. It also remembers the orders it has handled, so that a repeated event does not send the files twice. If sending fails, the server replies with an error. Stripe then retries the delivery, which is exactly what we want.

When does it make sense, and when not?

A webhook makes sense when an event in one system should start work in another straight away: a payment sends the files, a signed document changes the status in a client portal. It needs a sender that supports webhooks and a receiver with a public HTTPS address. For sales through Checkout, Stripe requires a webhook to fulfil orders, because the buyer does not always come back to your site after paying.

When the sender does not send webhooks, or a complete data set matters more than speed (a monthly report, reconciling payments), you are left with polling the API: asking for changes at regular intervals. Accounting software uses it, for example, to fetch new invoices from KSeF, Poland’s national e-invoicing system. The two are often combined: the webhook gives speed, and periodic polling catches events that went missing.

We build such connections, including ones with Microsoft 365 flows, as part of our Microsoft 365 automation service. Tell us what should happen after the event in your system. We usually reply within 1–2 working days, and after a short call you get a plan of work and a quote.

Describe your integration

What to watch out for

Spoofing. Without a signature check, anyone who knows the address can send a fake event, and your system will, for example, release files without payment or grant someone access. The signature is checked on the body exactly as it arrived, before the system does anything with it.
Repeats and order. The same event can arrive more than once and out of order. The receiver records which events it has handled and acts on each one only once; this property is called idempotency.
Different retry rules. Stripe retries a delivery in live mode for up to 3 days, Microsoft Graph for up to 4 hours, and GitHub does not retry automatically. If your server was down for longer, the missing events have to be fetched through the API afterwards.
Secret and address. The secret should be random and changed whenever a leak is suspected. In Power Automate, the address of the HTTP trigger can contain a SAS key that works like a password; after a leak, you can regenerate it.
Personal data. A payment event carries the buyer’s details: name, email address, billing details. Do not keep full event payloads in logs longer than necessary, and limit access to the logs to the people who need it.
Maintenance. Someone has to review failed deliveries (Stripe and GitHub show them in their dashboards) or get an alert when the receiving address returns errors.

Questions and answers

How is a webhook different from an API?

A webhook is part of the sender’s API. With an ordinary request, your system asks for data; with a webhook, the sender sends it by itself when something changes. That is why webhooks are sometimes called a ‘reverse API’.

Can Power Automate receive a webhook?

Yes. A flow with the ‘When an HTTP request is received’ trigger gets its own address and runs on every request. By default, new flows accept requests only from users in your organisation. Before you build the flow, check in the designer whether the trigger is marked Premium: if it is, a Microsoft 365 licence alone is not enough.