Articles in this section

Introduction to webhook listeners

Webhooks send an HTTP POST or PUT message over the web in real-time to an endpoint when an event occurs in an application. When an event triggers a webhook request, the source application sends a message to a specified URL, and a webhook listener receives the message and then executes operations according to the message’s content.

Why use webhooks?

Before webhook technology was available, if you wanted to sync information in two places across the web, one system would have to send repeating poll messages to review the status of the data in the system it needed to retrieve new information from, and then update data based on the responses to the poll requests. Webhook technology eliminates the necessity for constant polling by allowing one system to automatically send notification of a change to another system as soon as it occurs.

Webhooks in flows

The Celigo platform supports webhook technology as a source application. If you set up webhook settings within the administrative interface, or control panel, of your source application, you can configure listeners in the Celigo platform to receive messages and trigger integration flows based on that content. Setting up webhooks requires two steps:

  1. Configure a webhook in the source application for an event that triggers the HTTP POST or PUT message from the source application to the Celigo platform.

  2. Create a webhook listener in the Celigo platform to receive incoming information from the source application and initiate the flow with the data sent.

Tip

Organizations may use different terms for webhook technology. Consult the API documentation for your source app to determine how it refers to these concepts.

After creating the webhook, you can enable the flow for testing and trigger the source application to send a message to the webhook.

Caution

In your flow, the connection used in the step immediately following the listener must be available to receive data from the listener and continue downstream processing.

If you’d like to stop Celigo from receiving and/or processing data, change the callback URL in your source application or disable the flow. Refreshing a webhook’s token does not stop incoming messages from the source application. This behavior is intentional, so that refreshing a token reinitializes the configuration in the Celigo platform. It does not communicate with the source application to disable or change its callbacks. As a result, the source application will continue sending messages to the same endpoint URL. The only way to stop sending data is by disabling the webhook within your source application.

Webhook listener content types

Celigo platform webhook listeners can receive the following content types:

  • */xml

  • application/csv

  • application/json

  • application/text

  • application/x-www-form-urlencoded

  • text/csv

  • text/html

  • text/markdown

  • text/plain

  • text/plain; charset=utf-8

  • text/tab-separated-values

Tip

For incoming request content-type = text/plain, text/html, text/markdown, text/plain; charset=utf-8, or application/text, the listener captures the entire body into a field called _raw.

Rate limiting for Celigo platform APIs (including webhooks)

The Celigo platform uses a leaky-bucket algorithm for rate limiting, with a capacity of 1,000 tokens and a refill rate of 300 tokens per second, supporting up to 1,080,000 requests per hour. Remember that each connected application may have its own rate limits.

Leaky-bucket algorithm

  • Bucket size: Holds 1,000 tokens.

  • Fill rate: Adds 300 tokens per second.

This setup regulates request flow, preventing system overload.

Managing rate limits

  1. Understand limits: Know both Celigo platform and external application rate limits.

  2. Optimize requests: Minimize API calls.

  3. Handle errors: Prepare for rate limit breaches.

Rate limiting is vital for smooth integrations, and the Celigo algorithm –combined with an understanding of external limits – ensures efficient data exchange.