Webhook Relay

It includes admin settings for target webhook URLs, event selection, delivery status tracking, and retry handling for failed posts. The template is focused on forwarding platform events such as shift.created or leave_request.approved to external systems. It also includes a dashboard for recent deliveries so operators can see what was sent and what failed. This is a relay, not a full integration platform.

Use it for discrete platform events that need to trigger action elsewhere, such as approvals, assignments, status changes, or record creation. It works best when the event payload is already complete enough for the receiving system to act on. If you need complex transformation, branching workflows, or multi-step orchestration, this template may be too narrow. In that case, use it as the outbound delivery layer and keep transformation logic outside the app.

The template is designed to retry failed deliveries according to the retry rule you configure in the app. That makes it suitable for transient network errors and temporary downtime on the receiving side. It is not a substitute for guaranteed exactly-once delivery, so downstream systems should still be idempotent. A common pitfall is retrying without a deduplication key, which can create duplicate actions.

An admin or integration owner should manage webhook URLs, event subscriptions, and allowed domains. That role should be able to add or disable targets, review failed deliveries, and re-run retries when needed. Regular users should not edit delivery destinations because a bad URL can leak data or break downstream automations. Keeping this in a restricted role also makes change tracking easier.

It can be used for regulated workflows only if you carefully control which events are forwarded and which domains are allowed. For sensitive records, limit payloads to the minimum necessary fields and avoid sending unnecessary personal data. You should also confirm that the receiving endpoint is authorized to store or process the data. If your use case involves incident logs, visitor records, or other regulated events, review your retention and access rules before enabling forwarding.

The biggest mistakes are forwarding too many event types, sending to unapproved domains, and not checking delivery failures regularly. Another common issue is assuming the receiver will accept the exact payload shape without testing first. Teams also forget to define what happens after a failed retry, which leaves operators guessing. Start with one event type, one target, and a test payload before expanding.

This template is built around forwarding platform event payloads as-is, so it is best for straightforward relay use cases. If you need field mapping, filtering, or payload enrichment, you can customize the app around the relay logic or place a transformation step upstream. That keeps the template simple and easier to reason about. For many teams, the right pattern is to keep the relay thin and let the receiving system handle its own mapping.

Compared with ad-hoc scripts, this template gives you a visible list of targets, event subscriptions, delivery outcomes, and retries in one place. That reduces the risk of forgotten scripts, hidden failures, and one-off fixes that only one person understands. Compared with manual exports, it reacts immediately when the event happens instead of waiting for someone to notice and send data later. It is a better fit when the integration should be event-driven and repeatable.