Skip to main content
RevoEngine Webhooks are durable outbound HTTP attempts. Use them when RevoEngine should notify an external system asynchronously without holding an Endpoint response open.
This workspace does not create inbound subscriptions. To receive a partner callback, publish an authenticated Endpoint, validate the request, and then create a Job or Event.

Create a webhook in the UI

Open Webhooks and select Trigger webhook. The form exposes: The Platform API also supports searchable metadata, static-egress proxy, maskDetails, and controlled creator/system attribution.

Credentials and sensitive details

Static headers are persisted configuration. Do not place a long-lived API key in a screenshot, example, searchable metadata, or unmasked history. For stronger credential control, call the external API from a Component with api.httpCall() and resolve the credential from Secrets. This also lets you compute signatures, rotate versions, validate responses, and write a business transaction around the call. If a Webhook must contain a sensitive header, disable unnecessary detail retention and configure maskDetails for the persisted projection.

Attempt lifecycle

The Webhooks grid is operational history. A row records status, attempt count, scheduled time, elapsed time, payload size, creator, metadata, and—when retained—the request and attempt responses.
Cancellation stops eligible future processing; it cannot recall a request already accepted by the remote server. Delete and restore change platform visibility, not remote state.

Roles

Design for reliable delivery

The receiver should treat the custom ID or another stable business key as idempotent. A transport timeout is ambiguous: the receiver may have committed the request even though RevoEngine did not receive its response. Use metadata to correlate the webhook with the originating Job, Event history, or business object. Alert on terminal failure and exhausted attempts rather than every transient retry.
Verify that the same idempotency key was used on every attempt and that the receiver stores the first accepted result. Do not reduce retries as the primary duplicate-control mechanism.
Check scheduled time, current attempt, cancellation state, and platform delivery logs. Confirm the destination DNS, TLS, timeout, and static-egress allowlist.
Check saveDetails and masking policy. Absence from history can be intentional and does not mean an empty body was sent.

Production checklist

  • Require HTTPS.
  • Use an idempotency key understood by the receiver.
  • Set an explicit maximum attempt policy.
  • Mask or avoid credentials in retained request details.
  • Use static egress only when the receiver needs allowlisting.
  • Correlate the row with an operation or business ID.
  • Monitor terminal failure and cancellation.
See HTTP and Storage when the integration needs response handling or streamed files.
Last modified on September 5, 2026