Confluence Webhooks: Your Options on Cloud and Data Center
How to get webhooks out of Confluence — Data Center's native webhooks, Cloud's Automation web requests and Forge apps — plus payloads and testing.
Jira makes webhooks easy; Confluence makes you choose your own adventure. There is no "Webhooks" page in Confluence Cloud's admin UI, which surprises everyone who arrives from Jira — yet you can absolutely get page and comment events pushed to your code. This guide maps the three real options and their trade-offs, then covers securing and testing them. (Both products share Atlassian's delivery infrastructure — the same Atlassian Webhook HTTP Client that sends Jira webhooks.)
Option 1 (Cloud): Automation "Send web request"
The pragmatic choice for most teams. In space settings → Automation (or site-level automation):
- Create a rule with a trigger — Page published, Page updated, Comment added…
- Add the Send web request action.
- Set your URL, method
POST, content type JSON, and a body built from smart values:
{
"event": "page_published",
"pageId": "{{page.id}}",
"title": "{{page.title}}",
"space": "{{space.key}}",
"author": "{{page.lastModifiedBy.displayName}}",
"url": "{{page.url}}"
}
You define the payload, so your handler parses exactly what you designed — and you can set an Authorization header, which doubles as your authentication (Automation requests carry no signature). Limits to know: automation rules have monthly execution caps by plan, and complex conditions count against them.
Option 2 (Cloud): a Forge or Connect app
If you are building a product integration rather than internal glue, declare event subscriptions in an app. Forge apps subscribe to events like avi:confluence:published:page and get platform-managed delivery and auth; Connect apps register webhooks in their descriptor and receive JWT-authenticated calls. This is the marketplace-grade path — more setup, but no automation caps and proper identity.
Option 3 (Data Center/Server): native webhooks
Self-hosted Confluence has what Cloud lacks: Administration → Webhooks, where you register a URL against events — page created/updated/removed, blog posts, comments, attachments, space and user events. Payloads are JSON with the entity and event metadata, and configuring a secret adds an HMAC signature header (the same X-Hub-Signature pattern Jira uses — verify HMAC-SHA256 over the raw body; test values in the free HMAC verifier).
Which one?
| Situation | Use |
|---|---|
| Internal notification/sync on Cloud, quickly | Automation web request |
| Marketplace app or multi-tenant integration | Forge/Connect subscriptions |
| Data Center/Server instance | Native webhooks |
Testing the flow
Whatever the source, the receiving loop is the same as any webhook:
- Capture one first. Point the web request (or webhook) at a free Webhook Bin and trigger the event — you will see the exact headers and body before writing a line of handler code.
- Develop locally. Confluence Cloud can only reach public URLs; forward deliveries to your machine with the relay agent (
relay forward --bucket confluence http://localhost:8080/webhook) exactly as in the Jira local guide — same Atlassian plumbing, same pattern. - Replay captured events while you iterate instead of re-publishing pages.
Reliability notes
Automation web requests are fire-and-forget — a failed request is logged in the rule's audit log but not aggressively retried, so if the destination matters, front it with a stable endpoint that stores deliveries and retries towards your service. Data Center webhooks likewise treat delivery as best-effort; design your consumer to reconcile against the REST API when in doubt.