Webhook export

Before choosing webhook

Use webhook export when the customer owns an automation endpoint in Zapier, Make, n8n or an internal workflow. Webhook export sends a provider-neutral ticket payload to a customer-owned endpoint while WebRiskOps keeps the source finding, retry state and delivery diagnostics. Start from `/reports/{report}/ticket-exports` after the report finding or generated fix task is ready for automation handoff. Do not approve webhook export until the endpoint, payload, signing status and retry state are clear.

Export through a webhook

Follow the path `Ticket export source → Webhook target → Payload and signing check → Delivery retry or portable fallback`.

1. Open /reports/{report}/ticket-exports and select the report issue or generated fix task that the automation should receive. Result: source_type, source_id, severity, affected URL and evidence-safe links are visible before delivery.
2. Choose an active generic_webhook, webhook, zapier_webhook, make_webhook or n8n_webhook target. Result: provider_key identifies the customer-owned endpoint that will receive the payload.
3. Confirm webhook_url uses HTTPS and belongs to the customer or an approved self-hosted policy. Result: WebRiskOps does not send payloads to unsafe or unrelated endpoints.
4. Review webhook_payload before approval. Result: title, severity, category, affected URL, acceptance criteria and evidence-safe links are visible without raw private artifacts or secrets.
5. Confirm signing_status when signing is enabled. Result: the receiver can verify the payload without exposing webhook secrets in body fields.
6. Check retry_count and WEBHOOK_DELIVERY_FAILED diagnostics before re-approving. Result: transient failures remain retry scheduled instead of creating duplicate downstream work.
7. Use portable fallback after repeated failure or unsafe endpoint state. Result: the customer still receives CSV, Markdown or JSON handoff without weakening webhook safety.

Confirm webhook payload

Webhook payloads should be copy-safe for downstream automation.

• Include source type, source ID, title, severity, category, status and affected URL.
• Include optional fix task details, acceptance criteria, labels and evidence-safe links.
• Keep `provider_key`, `webhook_payload`, `signing_status` and `retry_count` visible in diagnostics.
• Preserve the same source identifiers so downstream tools can apply their own duplicate guard.
• Send an `Idempotency-Key` value for receivers that reject repeated deliveries.

Verify delivery safety

Webhook delivery must stop before unsafe data leaves WebRiskOps.

• Require an HTTPS endpoint owned by the customer or an approved self-hosted policy.
• Sign payloads when signing is enabled and show `signing_status` before approval.
• Do not include tokens, raw private artifact paths or unredacted personal data in the payload.
• Keep webhook secrets stored as credentials, not in body fields or documentation examples.

Retry and fallback states

Webhook errors should show the exact automated next step.

• `WEBHOOK_DELIVERY_FAILED` means review the endpoint status, retry state and last provider diagnostics.
• Rate limits or transient connection failures keep the export retry scheduled.
• Unsafe URL or missing credential means reconnect the webhook target before retrying.
• Repeated failure means generate CSV, Markdown or JSON through portable fallback.
• Secret or private artifact in webhook_payload means redact evidence before sending another delivery attempt.

Continue after webhook export

Continue to Portable export fallbacks when the endpoint is unsafe or repeatedly unavailable. Open API ticket export webhooks for endpoint fields and signing behavior, and use Status sync and duplicate handling when downstream automation creates a provider task that should be tracked.