Skip to main content

Additional Webhook Settings

Webhooks events also can be managed by additional settings. This page provides an overview of these settings.

Recieve All Webhooks​

This setting controls whether all webhook events are added to your processing queue or if you want to apply custom filtering logic.

When enabled (default):

  • All webhook events are added into queue as they occur
  • No filtering or conditional logic is applied
  • Simplest configuration for most use cases

When disabled:

  • You can provide a custom JavaScript script to evaluate each webhook event
  • The script determines which events should be sent and which should be skipped
  • Useful for reducing unnecessary big processing queue or processing only specific event types

Skip Webhooks by Script: When "Receive all webhooks" is disabled, you can write a JavaScript function to filter webhook events. The script should return:

  • TRUE - Skip this webhook event (do not add to queue)
  • FALSE - Add this webhook event to queue

Available Variables:

  • webhook.body - Raw webhook payload as string
  • webhook.jsonBody - Parsed JSON payload (if applicable)
  • Other webhook metadata depending on your implementation

Example Scripts:

// Skip webhooks with no body content
return !webhook.body && !webhook.jsonBody;
// Only send webhooks for specific event types
return webhook.jsonBody?.eventType !== 'user.created';
// Skip webhooks from test environments
return webhook.jsonBody?.environment === 'test';

Best Practices:

  • Keep scripts simple and performant to avoid delays
  • Test your filter logic thoroughly to avoid missing important events
  • Use the default example as a starting point: skip webhooks with no content
  • Consider logging skipped events for debugging purposes

Strict Order Processing​

This setting controls how webhook events are processed in queue.

When enabled (default):

  • Webhook events are processed one at a time in the exact order they were received
  • Each event must complete (successfully or after all retries) before the next one starts
  • Guarantees order preservation, which is critical for certain use cases
  • May result in slower overall throughput
  • If one event fails repeatedly, it blocks all subsequent events

When disabled:

  • Webhook events can be processed in queue for better performance even if previous are failed
  • Higher throughput and better resource utilization
  • Order is not strictly guaranteed
  • One failing event doesn't block others, but delayed and retried in 10 minutes

Skip Processing After Errors: When strict order processing is disabled, this setting provides a circuit breaker mechanism to protect your endpoint from being overwhelmed when it's experiencing issues.

How It Works:

  • The system tracks consecutive failures for each webhook endpoint
  • When the error threshold is reached, webhook processing is temporarily paused
  • This prevents the system from continuously sending requests to a failing endpoint
  • Processing can resume after manual intervention or automatic recovery

Configuration:

  • Minimum: 1 error (very sensitive, pauses quickly)
  • Maximum: 12 errors (more tolerant of transient issues)
  • Recommendation: 3-5 errors for most use cases The behaviour is affected also by pause rule after accumulated workflow errors.

Important Notes:

  • Only consecutive errors count toward the threshold
  • A successful delivery resets the error counter to zero
  • This setting is only available when "Strict order processing" is disabled
  • When strict order processing is enabled, a single failing event already blocks all subsequent events, making this setting unnecessary. Workflow will be paused after 12 errors.

Best Practices:

  • Set a lower threshold (1-3) for critical endpoints where failures indicate serious problems
  • Set a higher threshold (5-12) for endpoints that may experience transient network issues
  • Monitor your webhook logs to tune this value based on actual failure patterns
  • Implement proper error handling and retry logic in your webhook endpoint

Batch Processing​

Batch processing allows you to process multiple webhooks rather than each webhook separately.

When enabled (default):

  • Webhook events are processed by batch
  • If one webhook event is failed, then it fails whole batch
  • Webhook events are available in the workflow under the global variable “webhooks” (array) and "webhook" (object), if Batch Size is set to 1 The note: if set Batch Size is more than 1 and use "webhook" variable (object) in JS code then it will be failed with "webhook is not defined" error

This is particularly useful when:

  • Your workflow receives high volumes of webhook events
  • You want to reduce processing time and improve throughput
  • Your workflow code is optimized to process multiple webhooks at once

When disabled:

  • each webhook processed individually as it occurs
  • Webhook events are available in the workflow under the global variable “webhook” (object) and "webhooks" (array) with one item

Batch Size: The batch size determines how many webhooks are grouped together before being sent to workflow processing.

  • Minimum: 1 event
  • Maximum: 1,000 events
  • Recommendation: Choose a batch size based on your workflow processing capacity and acceptable latency

Larger batch sizes reduce the number of workflow runs but increase the payload size and may introduce memory issues. Smaller batch sizes provide more real-time delivery and stuck in webhook queue.

Update dateLastRun​

This setting controls whether the system maintains a timestamp of the last successfully processing.

When enabled (default):

  • The system updates a dateLastRun field after each successful webhook processing
  • The timestamp reflects when the webhook was processed, not when it was received
  • Only successful deliveries update this timestamp (failed attempts do not)
  • The value can be accessed for monitoring, reporting, or workflow logic

When disabled:

  • No timestamp tracking occurs
  • Suitable when you don't need to track webhook processing times