Integration using webhooks
Configure integration by using webhooks
Push, not poll
A webhook is an HTTP POST the platform sends to you when an event occurs. Azure DevOps calls these service hooks. The alternative — polling an API on a timer — is slower, wastes calls, and hits rate limits.
Configuration
| Element | Meaning |
|---|---|
| Event | What triggers it — build completed, PR created, work item updated |
| Filter | Narrow it — only this pipeline, only failures |
| Consumer / URL | Where the POST goes |
| Secret | Used to sign the payload so the receiver can verify it |
Two properties that shape the design
Delivery is at-least-once. A webhook can be delivered more than once — a retry after a timeout, for instance — so the receiver must be idempotent. Processing the same "build completed" event twice must not deploy twice.
Verify the signature. The endpoint is on the public internet, so anyone who learns the URL can post to it. The shared secret is what proves the payload came from the platform, and skipping that check turns your receiver into an open trigger.
Failure handling
Consumers fail. Log deliveries, monitor failures, and design so a missed webhook is recoverable — a reconciliation pass that catches up from the API is the usual answer, because at-least-once delivery is not the same as exactly-once.
Primary sources