Set connection rules

Set Delay interval​

Delay​

The delay rule allows you to introduce a delay between the moment Pabbly Hook receives an event, and when it's forwarded to your destination.

What is Delay?​

A delay in Pabbly Hook works similarly to delay settings in other webhook management platforms. It sets a waiting period between the receipt of a webhook trigger and the sending of the response, allowing for:

1. Controlled Processing - Allows for scheduled or delayed processing, ensuring webhook responses aren’t sent immediately, giving systems time to process each event without overwhelming resources.

Setting Up a Delay in Pabbly Webhooks​

This guide helps you set up a delay for webhook events in Pabbly Hook. Using delay settings, you can manage how long the system waits before sending the next webhook message. This can be especially useful when handling time-sensitive.

1. Go to Your Connection Settings:
   • Navigate to the specific webhook for which you want to apply a delay.
2. Locate the Delay Setting:
   • In the connection settings screen, find the "Delay" option (refer to the screenshot below for visual guidance).

3. Set the Desired Delay Time:

• Enter the delay time, typically in seconds or minutes, depending on your requirement.

Example : Enter the Delay Time

• In the delay settings, input a delay of 1 minute. This means that after an event is received by the webhook, there will be a 1-minute pause before it is processed and sent to the destination.

Save and Apply the Delay:

• After entering 1 minute as the delay time, save the configuration to apply it to the webhook and get the webhook url and copy that.(refer to the screenshot below for visual guidance).

Observe the Delay in Action:

• Once the delay is set, test the webhook by triggering an event to see how the delay affects the timing.
• After the event is triggered, check that the event doesn’t reach the destination immediately. Instead, it should be held in a queue by Pabbly Hook and only sent to the endpoint after the 1-minute delay(refer to the screenshot below for visual guidance).

Verify Delivery after 1 Minute:

• To confirm, monitor the destination endpoint and ensure the event is received exactly 1 minute after the trigger action was initiated(refer to the screenshot below for visual guidance).
• This allows you to check that the delay setting is working correctly and enforcing the 1-minute rate limit.

Using this configuration, you can effectively control the timing of event deliveries, which can prevent rate-limit issues with the receiving service or create a buffer to handle heavy webhook loads.

---

Set Transformation in Pabbly Hook​

Transformations​

A transformation lets you modify the payload of a event prior to delivery.

Transformations in pabbly hook allow you to modify, reformat, or map data from incoming webhook requests before passing it to the destination. transformations enable customized data handling and adjustments, which is especially useful when the incoming data doesn’t match the exact format needed by the receiving system. Transformations provide flexibility, allowing for operations such as renaming fields, changing values, adding or removing fields, and applying conditional logic.

Use Case Example: Adjusting Data Format for Compatibility​

Suppose an incoming webhook sends a payload with a date in MM/DD/YYYY format, but the receiving application needs it in YYYY-MM-DD format. A transformation can be applied to reformat this date before forwarding it.

You can use transformations to solve many problems. Here are a few common scenarios:

• Change payload formats: For example, converting XML to JSON
• Unify models across sources: For example, conforming WooCommerce orders and Shopify orders to a single standard
• Add compatibility when routing to an API: For example, adding keys and reformatting the payload
• Add additional properties to payloads: For example, to more clearly indicate the event type for use later in the pipeline in a filter or in your own application logic.

Filter rules are run after any transformation has been performed.

Transformations syntax​

Pabbly Hook allows for arbitrary transformations on request data using JavaScript (ES7).
Function : (request, context) => {
return request;
}

Setting up a Transformation​

1. Navigate to the Transformation Section: In Pabbly hook, locate the connection where you want to apply a transformation. Under the hook settings, find the "Transformations" section.
2. Click Transform to add a transformation rule.
3. Click Create new transformation.
4. Configure the transformation using the supported transformations syntax in the right-hand pane.

5. Define the Transformation Logic: You can specify transformations using code to alter the incoming request's body, headers, or path parameters and add code snippet for transformation.
6. Once written, test your transformation.

• The left pane's Input tab shows the request your transformation will be tested against. To change this request, click edit tab and select a recent payload, or edit the text directly.
• Click Run to test the transformation. Once run, the left pane's Output tab shows the resulting payload.

7. Once satisfied with the transformation, click Save.
8. Name the transformation using the input field in the pop-up box, clicking Save to save the transformation.

9. Make sure to select the saved transformation from dropdown and click Save again on the connection form to apply your changes.

Here’s an example code snippet to reformat a date field and rename a parameter for better compatibility.

10. From this point forward, events received on the connection are transformed prior to delivery to their destination.

Code:
(request, context) => {
  // Modify the `order_date` from `MM/DD/YYYY` to `YYYY-MM-DD`
  if (request.payload.order_date) {
    const [month, day, year] = request.payload.order_date.split('/');
    request.payload.order_date = `${year}-${month}-${day}`;
  }
 
  // Rename `orderID` to `order_id`
  if (request.payload.orderID) {
    request.payload.order_id = request.payload.orderID;
    delete request.payload.orderID;
  }
 
  // Example: Add a new field if `total_amount` is above a threshold
  if (request.payload.total_amount && request.payload.total_amount > 1000) {
    request.payload.high_value_order = true;
  }
 
    return request;
}

Transformation Code Example Explanation​

• Date Formatting: This code transforms order_date from MM/DD/YYYY to YYYY-MM-DD.
• Renaming Fields: It renames orderID to order_id for consistency.
• Adding Conditional Fields: If total_amount exceeds 1000, a new field high_value_order is added to indicate a high-value order.

# Example Transformation Code Including Payload , Headers , Query Params.

Code:
(request, context) => {
 
  // Modify the `order_date` from `MM/DD/YYYY` to `YYYY-MM-DD` in payload
  if (request.payload.order_date) {
    const [month, day, year] = request.payload.order_date.split('/');
    request.payload.order_date = `${year}-${month}-${day}`;
  }

  // Rename `orderID` to `order_id` in payload
  if (request.payload.orderID) {
    request.payload.order_id = request.payload.orderID;
    delete request.payload.orderID;
  }

  // Add a new field in payload if `total_amount` is above a threshold
  if (request.payload.total_amount && request.payload.total_amount > 1000) {
    request.payload.high_value_order = true;
  }

  // Modify `api_key` header for consistency
  if (request.headers['api_key']) {
    request.headers['API_KEY'] = request.headers['api_key'];
    delete request.headers['api_key'];
  }

  // Add a new header if `Content-Type` is missing
  if (!request.headers['Content-Type']) {
    request.headers['Content-Type'] = 'application/json';
  }

  // Update query param `status` from "pending" to "in_progress"
  if (request.queryParams.status === 'pending') {
    request.queryParams.status = 'in_progress';
  }

  return request;
}

Transformation Code Explanation​

• Payload Adjustments:
  • Reformats order_date to YYYY-MM-DD.
  • Renames orderID to order_id.
  • Adds high_value_order if total_amount is greater than 1000.
• Header Adjustments:
  • Renames api_key to API_KEY.
  • Sets Content-Type to application/json if it was missing.
• Query Parameter Adjustments:
  • Changes status from "pending" to "in_progress" if necessary.

Input Example​

Here’s an example of how the input might look before applying the transformation:

Output Example​

After applying the transformation, the output will look like this:

Edit a transformation​

Editing a transformation changes how payload data is transformed before delivery.

1. Open the connection rules configuration.
2. Navigate to the Transformation Section: Choose the transformation you want to update.
3. Next to the transformation rule, click Editor Button(Screenshot for your's refrence).
   
   
4. Configure the transformation using the supported transformation syntax in the right-hand pane.
5. Once written, test your transformation.
   • The left pane's Input tab shows the request your transformation will be tested against. To change this request, click Change and select a recent payload, or edit the text directly.
   • Click Run to test the transformation. Once run, the left pane's Output tab shows the resulting payload.
6. Optionally, you may rename the transformation using the input field in the pop up box. Click Update to confirm the name change.
   
   
7. Once satisfied, click Update.
8. Make sure to click Update again on the connection form to apply your changes.

Keep in mind that updating a transformation will affect all connections that use the same transformation. If this is not your desired behavior, you can create a new one.

---

Transformation Modal View in Pabbly Hook​

Definition​

The Transformation Modal View in Pabbly Hook allows users to view and manage the details of a specific transformation created within the system. This feature is accessible by selecting a transformation from the "Transformations" list on the left-hand side vertical navigation bar.

---

Features and Fields Explained​

1. Transformation Name​

• Location: Top of the modal, prominently displayed.
• Purpose: Identifies the name of the selected transformation for quick reference.
• Editable: No, it reflects the name assigned during transformation creation.

2. Created At​

• Location: Below the transformation name.
• Purpose: Indicates the exact timestamp when the transformation was initially created.
• Format: Follows the MMM DD, YYYY HH:MM:SS format for easy readability.

3. Transformation ID​

• Location: Listed alongside other metadata.
• Purpose: Provides a unique identifier for the transformation. This is particularly useful for debugging or referencing the transformation in API calls.
• Editable: No, it is automatically generated by the system.

4. Last Updated At​

• Location: Next to the "Created At" field.
• Purpose: Displays the most recent timestamp when the transformation was modified. Useful for tracking changes.
• Format: Same as the "Created At" field.

5. Transformation Code​

• Location: In the main content section of the modal.
• Purpose: Shows the actual JavaScript code used for the transformation.
• Key Features:
  • Syntax Highlighting: Ensures better readability of the code.
  • Code Examples: Includes comments for common use cases, such as:
    • Changing date formats.
    • Renaming fields.
    • Adding conditional fields based on specific logic.

Example Use Cases in Transformation Code​

1. Change Date Format:
   
   if (request.payload.order_date) {
   const [month, day, year] = request.payload.order_date.split('/');
   request.payload.order_date = `${year}-${month}-${day}`;
   }
   
   
2. Rename Fields:
   if (request.payload.orderID) {
   request.payload.order_id = request.payload.orderID;
   delete request.payload.orderID;
   }
   
   
3. Add Conditional Fields:
   
   if (request.payload.total_amount && request.payload.total_amount > 1000) {
   request.payload.high_value_order = true;
   }

Click to expand...
Click to expand...

---

How to Use the Transformation Modal​

1. Viewing Transformation Details:
   • Navigate to the "Transformations" section from the sidebar.
   • Click on the desired transformation ID to open the modal view.

---

1. Editing Transformation Code:

• Locate the "Transformation Code" section.
• Modify the code as needed. For example:
  • Change the date format from MM/DD/YYYY to YYYY-MM-DD.
  • Rename fields or add custom logic using JavaScript.

---

1. Saving Changes:
   • After making modifications, click the "Update" button (if available).

---

1. Debugging:
   • Use the Transformation ID to trace logs or identify issues in webhook integrations.

Additional Note on "Created At" Field​

The "Created At" field in the transformation modal includes a timezone specification in the format:

Transformation Created: November 29, 2024 16:09:39 (UTC +05:30) Asia/Kolkata

---

Explanation​

1. Purpose:
   • The inclusion of the timezone ensures clarity about the specific time zone the timestamp refers to. This is particularly useful in scenarios involving global teams or when debugging logs and events that occur across multiple time zones.
2. Components:
   • Date and Time: November 29, 2024 16:09:39.
   • UTC Offset: (UTC +05:30).
   • Time Zone Region: Asia/Kolkata.
3. Display:
   • This detail is prominently displayed below the "Transformation Name," ensuring it is visible and easy to understand.

---

Usage Implications​

• Debugging:
  • When comparing timestamps in logs or events from other systems, ensure alignment with the specified timezone.
• Global Team Collaboration:
  • Facilitates smooth communication by providing clarity about the timezone when a transformation was created.
• Compliance and Auditing:
  • Useful for timestamp validation in regions where precise logging and timezone tracking are required for compliance.

This additional detail ensures that users can track transformations with precision, even in a multi-time-zone environment.

---

Best Practices​

• Validate Code: Before saving, ensure your JavaScript code is error-free to avoid runtime issues.
• Test Changes: Test the transformation using sample payloads to confirm it behaves as expected.

---

This documentation provides a comprehensive understanding of the transformation modal view in Pabbly Hook, ensuring users can efficiently manage and customize their transformations.

---

​

Set Custom Response in Pabbly Hook​

Custom responses​

A Custom Response allows you to control the response that your webhook sends back to the source of a request. This can be useful if you need to:

• Modify the content type of the response (e.g., JSON, plain text)
• Dynamically adjust the response content based on request data (such as data in the request body, query parameters, or headers)
• Tailor responses based on specific requirements from external systems or API integrations.

Why Use a Custom Response?​

Custom responses are helpful when:

1. You want to dynamically replace parts of the response with incoming request data.
2. You need to meet a specific content-type requirement, especially when working with APIs that expect responses in formats other than JSON.
3. You aim to streamline response handling, directly from the webhook.

Some API vendors modify their behavior based on the response they receive from a request. For these providers, pabbly hook supports setting custom responses to satisfy their requirements.

How to Set a Custom Response in Pabbly Hook​

To set a custom response, follow these steps:

1. Navigate to the Custom Response Section: In Pabbly hook, locate the connection where you want to apply a custom response. Under the hook settings, find the "Custom Response" section.
2. Activate the Custom Response: Mark the custom response as active to enable it for the webhook.
3. Configure the custom response using Content Type and Content.
4. Specify the Content Type: Choose the appropriate content type (e.g., application/json, text/plain) to ensure the response meets any specific format requirements.
5. Define the Custom Response Content: Customize the response content with placeholders to insert request data dynamically.
   • Use $request.body.<key>$ to replace placeholders with values from the request body.
   • Use $request.query.<key>$ for values from query parameters.
   • Use $request.headers.<key>$ for values from headers.
     
     
     
6. Once satisfied with the custom response, click Save.
7. Now you can send the webhook and check the custom response(Below is the screen shot for your reference).
   
   
   
   
   
8. Now you see the custom response while triggering the webhook(Below is the screen shot for your reference).
   
   
   
   
   

Note: If there is no key provided then the custom response value will be empty for that key(Below is the screen shot for your reference).
Example : I will not send name in body.

---

Set Filter in Pabbly Hook​

In Pabbly Hook, Filters allow you to permit events conditionally based on the contents of their Headers, Body, Query, or Path.
Purpose of Filters: Filters in Pabbly hooks allow you to control which webhook requests are processed based on specific criteria. They help ensure that only relevant requests trigger actions, making the process efficient and targeted. Filters can be applied to the body, headers, query parameters, and path segments of incoming requests. In simple words ,A filter is a condition or rule applied to incoming data to determine if it should be processed further or blocked the request based on condition.

Use Case for Rate Filters:

• Allowing only events with useful information to pass through to a destination.

Filters syntax
Filters utilize JSON, and support matching on any value (string, number, boolean, null), on nested objects, and on arrays. There is also support for special operators. For a full rundown of supported schema.

1. Body Filter​

A Body Filter is used to apply rules on the content within the request body. This type of filter is useful when you need to check if certain fields in the payload contain specific values.

• Example: Body Filtering on the status field to process only messages with "status": "active".

View attachment 49227

• If "status": "active" is not matched in body it will block the request.
• Example: Filtering on the status field to process messages with "status": "Inactive".

2. Header Filter​

A Header Filter checks specific headers in the request, allowing you to validate metadata or control data processing based on headers.

• Example: Header Filtering on Content-Type to process only requests where "Content-Type": "application/json".

• If "Content-Type": "application/json" is not matched it will block the request.
• Example: Filtering on the Content-Type field to process messages with "Content-Type": "plain/text".

3. Query Filter​

A Query Filter is used to filter requests based on query parameters. This is helpful when specific information, like IDs or action types, is passed as URL query parameters.

• Example: Query Params Filtering on the user_id query parameter to process requests only for a specific user "user_id":"12345".

• If "user_id":"12345" is not matched it will block the request.
• Example: Filtering on the field to process messages with "user_id":"678910".

Complex matches using operators.​

Operators allow for more complex matching strategies, beyond simple equivalency tests.

Operator	Supported Type	Description
$gte	number, string	Greater than or equal to
$gt	number, string	Greater than
$lt	number, string	Less than
$lte	number, string	Less than or equal to
$eq	array, number, object, string	Equal (or deep equal)
$neq	array, number, object, string	Not Equal (or deep not equal)
$in	array, string	Contains
$nin	array, string	Does not contain
$startsWith	string	Starts with text
$endsWith	string	Ends with text
$or	array	Array of conditions to match
$and	array	Array of conditions to match
$exist	boolean	Undefined or not undefined
$not	Valid syntax	Negation

1. Value Operators​

These operators are used for comparisons between values such as numbers, dates, or even strings.

• $eq: Matches if the value is equal to the specified value.
• $neq: Matches if the value is not equal to the specified value.
• $lt: Matches if the value is less than the specified value.
• $lte: Matches if the value is less than or equal to the specified value.
• $gt: Matches if the value is greater than the specified value.
• $gte: Matches if the value is greater than or equal to the specified value.
• $in: Matches if the value is in the array.

Example:​

Code:
{
"product": {
"price": {
             "$gte": 100,
              "$lte": 500
             },
"category":  {
"$in": ["electronics", "furniture"]
                    }
                }
}

• Explanation: This filter will match if the price of the product is between 100 and 500, and the category is either "electronics" or "furniture".

Example passing payload:

Code:
{
  "product": {
    "price": 250,
    "category": "electronics"
  }
}

Blocking Payload​

For the payload to block, any of the following can be true:

• price is less than 100 or greater than 500
• category is not "electronics" or "furniture"

Example blocking payload:

Code:
{
  "product": {
    "price": 50,
    "category": "clothing"
  }
}

This way, any payload outside the specified range for price or category would result in the request being blocked by the filter.

2. String Operators​

These operators are useful for pattern matching or working with string values.

• $contains: Matches if the string contains the specified value.
• $notContains: Matches if the string does not contain the specified value.
• $startsWith: Matches if the string starts with the specified value.
• $endsWith: Matches if the string ends with the specified value.
• $regex: Matches if the string matches the given regular expression.

Example:​

Code:
{
  "product": {
    "title": {
      "$startsWith": "Smart",
      "$regex": {
        "pattern": "Pro$",
        "flags": "i"
      }
    }
  }
}

• Explanation: This filter matches products where the title starts with "Smart" and ends with "Pro" (case-insensitive).

To satisfy the filter : The product.title in the payload should start with "Smart" and end with "Pro" (case-insensitive). Here are examples of payloads that would pass and block according to this filter.

---

Passing Payload​

Code:
{
"product": {
"title": "SmartPhone Pro"
}
}

• Explanation: The title starts with "Smart" and ends with "Pro", meeting both the $startsWith and $regex conditions.

---

Blocking Payload​

1. Title does not start with "Smart":
   Code:
   {
   "product": {
   "title": "Phone Pro"
   }
   }
2. Title does not end with "Pro":
   Code:
   {"product": {
   "title": "SmartPhone Plus"
   }
   }
3. Title starts with "Smart" but is case-sensitive mismatch for regex:
   Code:
   {"product": {
   "title": "smart Pro"
   }
   }

Each of these examples fails to meet the combined requirements of $startsWith and $regex.

---

3. Existence Operators​

These operators deal with the presence or absence of certain fields.

• $exists: Matches if the field exists or not.
• $empty: Matches if the field is empty or not (works for strings, arrays, and objects).

Example:​

Code:
{
  "user": {
    "email": {
      "$exists": true
    },
    "address": {
      "$empty": false
    }
  }
}

Here's how to structure the payload to pass and block the request based on the provided filter:

Explanation of the Filter:​

• user.email.$exists: true — The payload must have an email field under user.
• user.address.$empty: false — The address field under user should not be empty (for strings, this means it shouldn't be an empty string ""; for arrays, it shouldn't be []; for objects, it shouldn't be {}).

Payload for Passing (matches filter):​

Code:
{
"user": {
"email": "[email protected]",
"address": "123 Main St, Springfield"
}
}

Payload for Blocking (does not match filter):​

1. Missing email:
   Code:
   {
   "user": {
   "address": "123 Main St, Springfield"
   }
   }
2. Empty address:
   Code:
   {
   "user": {
   "email": "[email protected]",
   "address": ""
   }
   }

Each of these blocking examples fails one part of the filter criteria, so they would result in the request being blocked.

• Explanation: This filter will match users that have an email field and whose address field is not empty.

---

4. Logical Operators​

Logical operators allow you to combine multiple conditions.

• $and: Matches if all of the specified conditions are true.
• $or: Matches if any of the specified conditions are true.
• $not: Matches if the specified condition is false.

Example (nested with logical operators):​

Code:
{
  "$or": [
    {
      "product": {
        "price": {
          "$lt": 50
        }
      }
    },
    {
      "$and": [
        {
          "product": {
            "category": {
              "$eq": "clothing"
            }
          }
        },
        {
          "product": {
            "availability": {
              "$eq": "in_stock"
            }
          }
        }
      ]
    }
  ]
}

• Explanation: This filter matches if the price of the product is less than 50, or if the category is "clothing" and the product is in_stock.

The filter will pass if:

1. product.price is less than 50.
2. OR product.category is "clothing" and product.availability is "in_stock".

1. Payload to Pass the Filter:​

The following payload meets the filter because product.price is less than 50.

Code:
{
"product": {
"price": 45,
"category": "electronics",
"availability": "out_of_stock"
}
}

Alternatively, this payload also passes because product.category is "clothing" and product.availability is "in_stock":

Code:
{
"product": {
"price": 100,
"category": "clothing",
"availability": "in_stock"
}
}

2. Payload to Block the Filter:​

The following payload does not meet any condition and thus would be blocked:

Code:
{
"product": {
"price": 75,
"category": "electronics",
"availability": "out_of_stock"
}
}

In this blocked payload, product.price is not less than 50, product.category is not "clothing", and product.availability is not "in_stock".