---
title: "Confluence Webhooks: Your Options on Cloud and Data Center | WebhookRelay"
meta:
  "og:description": "How to get webhooks out of Confluence — Data Center's native webhooks, Cloud's Automation web requests and Forge/Connect apps — plus payload notes, security and testing."
  "og:title": "Confluence Webhooks: Your Options on Cloud and Data Center"
  description: "How to get webhooks out of Confluence — Data Center's native webhooks, Cloud's Automation web requests and Forge/Connect apps — plus payload notes, security and testing."
---

![Stripes](https://webhookrelay.com/blog/confluence-webhooks/images/stripes.svg)

# **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/Connect apps — plus payload notes, security and testing.

![Confluence webhooks guide](https://webhookrelay.com/blog/confluence-webhooks/images/blog/heroes/route.jpg)

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](https://webhookrelay.com/blog/confluence-webhooks/blog/jira-webhooks-guide/).)

## [Option 1 (Cloud): Automation "Send web request"](#option-1-cloud-automation-send-web-request)

The pragmatic choice for most teams. In **space settings → Automation** (or site-level automation):

1. Create a rule with a trigger — _Page published_, _Page updated_, _Comment added_…
2. Add the **Send web request** action.
3. 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](#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](#option-3-data-centerserver-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](https://webhookrelay.com/blog/confluence-webhooks/hmac-verification/)).

## [Which one?](#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](#testing-the-flow)

Whatever the source, the receiving loop is the same as any webhook:

1. **Capture one first.** Point the web request (or webhook) at a free [Webhook Bin](https://webhookrelay.com/blog/confluence-webhooks/webhook-bin/) and trigger the event — you will see the exact headers and body before writing a line of handler code.
2. **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](https://webhookrelay.com/blog/confluence-webhooks/blog/receive-jira-webhooks-locally/) — same Atlassian plumbing, same pattern.
3. **Replay** captured events while you iterate instead of re-publishing pages.

## [Reliability notes](#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](https://webhookrelay.com/blog/confluence-webhooks/features/durable-retries/). Data Center webhooks likewise treat delivery as best-effort; design your consumer to reconcile against the REST API when in doubt.

## [Related reading](#related-reading)

- [Jira webhooks: setup, payload and security](https://webhookrelay.com/blog/confluence-webhooks/blog/jira-webhooks-guide/) — the sibling guide
- [Test Jira webhooks locally](https://webhookrelay.com/blog/confluence-webhooks/blog/receive-jira-webhooks-locally/)
- [How to test webhooks](https://webhookrelay.com/blog/confluence-webhooks/blog/how-to-test-webhooks/)
- [What is a webhook](https://webhookrelay.com/blog/confluence-webhooks/blog/what-is-webhook/)