Webhooks and audit log
Configure publication notifications
The operator must configure WEBHOOK_ENCRYPTION_KEY and enable webhook processing first. Administrators can then:
- Open Webhooks and create a subscription.
- Enter its name and public HTTPS destination.
- Select publication/unpublication events and content types. An empty type selection means all types.
- Save and securely copy the signing secret shown after creation.
- Send a test delivery, then inspect deliveries and attempts.
Test events do not change content. Destinations must use public HTTPS on port 443; private, loopback, reserved, credential-bearing, and redirecting destinations are unsupported.
Signing secrets are shown fully only on creation or explicit replacement. The list shows a masked identifier. Coordinate replacements with the receiver, since in-flight requests may use the previous secret.
Inspect failures
Inspect the delivery and its attempts before retrying. Transient failures retry automatically within bounded limits. Fix persistent destination or configuration errors before manually retrying failed deliveries.
Editing a subscription cancels queued deliveries; disabling also stops new delivery creation. Requests already sent may still arrive. Delivery is at least once with no ordering guarantee, so the receiving application must verify signatures and deduplicate event IDs. Coordinate event handling with the team maintaining the receiving application.
Failed notification delivery does not roll back successful publication. Use job monitoring to distinguish content publication from downstream notification status.
Review activity
Open Audit Log, use its available filters, and inspect event details. Audit records help investigate administrative and content actions, including emergency publication reasons. Compare actors, timestamps, and targets with entry history and release status.
Audit Log is an activity record, not a restore interface. Use revision history for content recovery and full backups for deployment recovery.