Use signed webhooks when certificate warnings should trigger internal automation.

Endpoint setup

Use the integration page to decide what automation should happen, then use the webhook docs for payload and signature implementation. Add an HTTPS receiver URL in the dashboard, store the one-time signing secret in your receiver configuration, and rotate it from the channel page when ownership changes.

• Use HTTPS receivers your team operates or is authorized to configure.
• Store the generated signing secret outside source code.
• Rotate the channel secret after receiver migrations or suspected exposure.
• Treat receiver failures as alert-path issues, not as certificate state.

Automation examples

Signed certificate events can update systems that already own operational follow-up. Keep the receiver narrow so certificate alerts create useful work instead of noisy automation.

• Create tickets only for events that need human follow-up.
• Filter webhook routes by event class and expiry window before creating tickets.
• Update inventory on certificate-change events instead of every routine check.
• Keep receiver logs tied to delivery IDs for troubleshooting.

Signature verification belongs in the docs

The webhook docs cover raw-body signature verification, replay tolerance, retry behavior, payload fields, idempotency, and secret rotation. Use this integration page to choose the workflow; use the docs before acting on received payloads.

Retries and logs

Transient HTTP or network failures retry on the alert delivery schedule. Each attempt remains visible with status and provider error text when available.