Generic webhook automation setup

Before connecting webhook automation

Use this page when the customer owns an automation endpoint in Zapier, Make, n8n or an internal HTTPS receiver and wants WebRiskOps to send signed provider-neutral ticket export payloads there. Setup records the endpoint, provider key, signing credential, URL safety decision and revoke path before any report finding or fix task is delivered. Start from `/settings` after Cloud and self-hosted integrations confirms the customer needs a webhook-only target instead of a native tracker. Do not save a production webhook target until the endpoint host, signing secret, private-network policy and revoke path are clear.

Connect a webhook automation target

Follow the path `Cloud and self-hosted integrations → Generic webhook automation target → Endpoint and signing check → Webhook export → Retry or portable fallback`.

1. Open /settings and review Integration status, then choose Generic webhook automation setup. Result: provider_key is recorded as generic_webhook, webhook, zapier_webhook, make_webhook or n8n_webhook before endpoint fields are requested.
2. Choose deployment_mode for a public SaaS hook or customer-approved self-hosted automation endpoint. Result: URL safety knows whether base_url must be public HTTPS or may use an approved private-network policy.
3. Enter the customer-owned webhook_url or base_url exactly as supplied by Zapier, Make, n8n or the internal receiver. Result: unsafe redirects, local URLs, credentials in URLs and unapproved private hosts are blocked before any payload leaves WebRiskOps.
4. Add signing_secret or webhook_secret and store it as the webhook credential. Result: WebRiskOps can send X-WebRiskOps-Signature with HMAC-SHA256 without putting the secret in webhook_payload.
5. Confirm the receiver verifies X-WebRiskOps-Event, X-WebRiskOps-Schema, X-WebRiskOps-Idempotency-Key, X-WebRiskOps-Timestamp, X-WebRiskOps-Nonce and X-WebRiskOps-Signature. Result: stale, replayed, duplicate or unsigned deliveries can be rejected downstream.
6. For self-hosted n8n or internal endpoints, confirm private_network_policy and private_network_allowlist only after the customer authorizes that route. Result: WebRiskOps does not post evidence to an unauthorized private network.
7. Save only when the endpoint host, provider key, signing summary and receiver owner match the customer workflow. Result: the webhook target is available to ticket export without exposing secrets in documentation or support messages.
8. If generic_webhook_secret_missing or PROVIDER_AUTH_REQUIRED appears, add or rotate the signing secret before retrying. Result: outbound payloads stay blocked until a credential can sign them.
9. If generic_webhook_url_unsafe, generic_webhook_redirect_blocked or PROVIDER_BASE_URL_BLOCKED appears, fix the endpoint URL or use portable fallback. Result: unsafe URLs, redirects and unauthorized private hosts do not receive evidence.
10. Continue to Webhook export after setup. Result: ticket-export.webhook.v1, ticket_export.requested, idempotency_key and retry behavior use the same webhook provider record.

Configure webhook signing and URL safety

Webhook automation setup should make delivery safety visible before exports begin.

• `generic_webhook`, `webhook`, `zapier_webhook`, `make_webhook` and `n8n_webhook` are the supported webhook provider keys.
• `base_url` stores the endpoint URL even when the UI label says webhook_url.
• `signing_secret`, `webhook_secret` or `secret` should be stored only as a credential payload, never in webhook body fields.
• WebRiskOps sends `X-WebRiskOps-Event`, `X-WebRiskOps-Schema`, `X-WebRiskOps-Idempotency-Key`, `X-WebRiskOps-Timestamp`, `X-WebRiskOps-Nonce` and `X-WebRiskOps-Signature` with each delivery.
• The payload uses schema_version `ticket-export.webhook.v1` and event `ticket_export.requested`.
• Receiver-side `WEBHOOK_SIGNATURE_INVALID` means the endpoint rejected the HMAC signature; rotate the secret or fix timestamp, nonce and raw-body verification before retrying.
• Revoke access by deleting or rotating the receiver URL and signing secret first, then disconnecting the WebRiskOps webhook target.

Ready webhook automation states

Continue only when the endpoint can safely receive signed payloads.

• Provider key ready means `provider_key` is generic_webhook, webhook, zapier_webhook, make_webhook or n8n_webhook.
• Endpoint ready means base_url or webhook_url is HTTPS and belongs to the customer-owned receiver.
• Signing ready means signing_secret or webhook_secret exists as a credential and the receiver knows how to verify X-WebRiskOps-Signature.
• Replay protection ready means the receiver checks idempotency_key, timestamp and nonce before creating downstream work.
• Private-network ready means private_network_policy and private_network_allowlist are documented when the endpoint is self-hosted.
• Revoke path ready means the customer knows where to rotate or delete the receiver URL and secret before disconnecting WebRiskOps.

Blocked webhook setup states

Blocked webhook setup should explain exactly what to fix.

• `generic_webhook_secret_missing` means add signing_secret or webhook_secret before saving or retrying export.
• `generic_webhook_url_unsafe` means the endpoint is local, reserved, credential-bearing, malformed or not allowed by the private-network policy.
• `generic_webhook_redirect_blocked` means the endpoint redirected the request; update base_url to the final HTTPS endpoint before retrying.
• `PROVIDER_BASE_URL_BLOCKED` means the target cannot pass URL safety for automated outbound delivery.
• `WEBHOOK_SIGNATURE_INVALID` means the receiver rejected the signature and should not create downstream work.
• `WEBHOOK_DELIVERY_FAILED` during export means review endpoint availability, retry state and portable fallback before approving another delivery.

Continue after webhook setup

Continue to Webhook export when the endpoint and signing check are ready. Open API ticket export webhooks for header, schema and HMAC verification details, use Portable export fallbacks when the endpoint cannot be made safe, use Status sync and duplicate handling when downstream automation creates trackable work, or return to ClickUp setup when the customer prefers a native work management list.