Skip to content

Commit

Permalink
minor update
Browse files Browse the repository at this point in the history
  • Loading branch information
WanYixian committed Dec 9, 2024
1 parent 063e716 commit fc8fdf5
Show file tree
Hide file tree
Showing 5 changed files with 24 additions and 26 deletions.
5 changes: 2 additions & 3 deletions integrations/sources/eventbridge-webhook.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,7 @@ create table wbhtable (
| :--------- | :-----------|
| `data JSONB` | Defines the name of column to store the JSON payload from the webhook. Currently, only `JSONB` type is supported for webhook tables. |
| `headers->>'...'` | Extracts the signature provided by Amazon EventBridge in the `authorization` HTTP header. The header key can be any string value and you can specify it when you create your webhook destination for RisingWave. <br/> <br/> In `secure_compare()` function, the whole HTTP header is interpreted as a JSONB object, and you can access the header value using the `->>` operator, but only the lower-case header names in the `->>` operator, otherwise the verification will fail. |
| test_secret | Provides the expected signature. In the example above, we directly compare the secret value of `test_secret` with the signature provided in the headers to verify the requests. |
| `test_secret` | Provides the expected signature. In the example above, we directly compare the secret value of `test_secret` with the signature provided in the headers to verify the requests. |
| `secure_compare(...)` | Validates requests by matching the header signature against the computed signature, ensuring only authenticated requests are processed. The `secure_compare()` function compares two strings in a fixed amount of time, regardless of whether they are equal or not, ensuring that the comparison is secure and resistant to timing attacks. |

## 3. Set up webhook in Amazon EventBridge
Expand Down Expand Up @@ -81,8 +81,7 @@ Sign in to the AWS Management Console and navigate to **Amazon EventBridge**.
<Step>
Create or Select an Event Bus:
- In the EventBridge console, go to **Event buses**.
- You can use the default event bus or create a new custom event bus.
- To create a new event bus, click **Create event bus**, provide a name, and click **Create**.
- You can use the default event bus or create a new custom event bus. To create a new event bus, click **Create event bus**, provide a name, and click **Create**.
</Step>
<Step>
Create a Rule for the Event Bus:
Expand Down
6 changes: 3 additions & 3 deletions integrations/sources/hubspot-webhook.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ sidebarTitle: HubSpot webhook

HubSpot is a CRM platform that provides various marketing, sales, and customer service features. It allows you to leverage webhooks through its workflow automation features. With these webhooks, you can receive real-time HTTP POST requests whenever specific events occur—such as a contact filling out a form or a deal reaching a certain stage—and forward that data to other systems. For example, you can automatically post a contact’s information to another CRM once they complete a form submission, or send deal details to an external shipment-handling system to initiate a purchase order. By integrating these HubSpot webhooks with RisingWave, you gain the ability to ingest and process this event data within your database, enabling real-time analytics and deeper insights into user behavior and engagement.

HubSpot Webhooks are not available on all HubSpot plans. You must have the appropriate subscription level (e.g., certain Operations Hub Enterprise plans) to access HubSpot Webhook functionality. Check your HubSpot plan details before proceeding.
HubSpot webhooks are not available on all HubSpot plans. You must have the appropriate subscription level (e.g., certain Operations Hub Enterprise plans) to access HubSpot Webhook functionality. Check your HubSpot plan details before proceeding.

This guide will walk through the steps to set up RisingWave as a destination for HubSpot webhooks.

Expand Down Expand Up @@ -50,7 +50,7 @@ CREATE TABLE wbhtable (
| :--------- | :-----------|
| `data JSONB` | Defines the name of column to store the JSON payload from the webhook. Currently, only `JSONB` type is supported for webhook tables. |
| `headers->>'...'` | Extracts the signature provided by HubSpot in the `x-hubspot-signature` HTTP header. <br/> <br/> In `secure_compare()` function, the whole HTTP header is interpreted as a JSONB object, and you can access the header value using the `->>` operator, but only the lower-case header names in the `->>` operator, otherwise the verification will fail. |
| encode(...)` | Computes the expected signature by concatenating the secret, HTTP method (`POST`), RisingWave Webhook URL (`http://127.0.0.1:4560/webhook/dev/public/` in this example), and the request body converted from UTF-8 `data`. It then takes a `SHA-256` hash of this string and encodes it in hex. |
| `encode(...)` | Computes the expected signature by concatenating the secret, HTTP method (`POST`), RisingWave Webhook URL (`http://127.0.0.1:4560/webhook/dev/public/` in this example), and the request body converted from UTF-8 `data`. It then takes a `SHA-256` hash of this string and encodes it in hex. |
| `secure_compare(...)` | Validates requests by matching the header signature against the computed signature, ensuring only authenticated requests are processed. The `secure_compare()` function compares two strings in a fixed amount of time, regardless of whether they are equal or not, ensuring that the comparison is secure and resistant to timing attacks. |

In HubSpot Webhook, several request validation methods are available, including v1, v2, v3, and API Key–based authentication. Each version employs a different approach to generating and verifying signatures, and may store the signature in a distinct header field. The SQL example above illustrates how to validate a signature generated using the v2 method.
Expand All @@ -71,7 +71,7 @@ https://<HOST>/webhook/<database>/<schema_name>/<table_name>
| Parameter | Description |
|-----------|-------------|
| `HOST` | The hostname or IP address where your RisingWave instance is accessible. This could be a domain name or an IP address. |
| `database` | The name of the RisingWave database where your table resides |
| `database` | The name of the RisingWave database where your table resides. |
| `schema_name` | The schema name of your table, typically `public` unless specified otherwise. |
| `table_name` | The name of the table you created to receive webhook data, e.g., `wbhtable`. |

Expand Down
8 changes: 4 additions & 4 deletions integrations/sources/rudderstack-webhook.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@ create table wbhtable (
| :--------- | :-----------|
| `data JSONB` | Defines the name of column to store the JSON payload from the webhook. Currently, only `JSONB` type is supported for webhook tables. |
| `headers->>'...'` | Extracts the signature provided by RudderStack in the `authorization` HTTP header. The header key can be any string value and you can specify it when you create your webhook destination for RisingWave. <br/> <br/> In `secure_compare()` function, the whole HTTP header is interpreted as a JSONB object, and you can access the header value using the `->>` operator, but only the lower-case header names in the `->>` operator, otherwise the verification will fail. |
| test_secret | Provides the expected signature. In the example above, we directly compare the secret value of `test_secret` with the signature provided in the headers to verify the requests. |
| `test_secret` | Provides the expected signature. In the example above, we directly compare the secret value of `test_secret` with the signature provided in the headers to verify the requests. |
| `secure_compare(...)` | Validates requests by matching the header signature against the computed signature, ensuring only authenticated requests are processed. The `secure_compare()` function compares two strings in a fixed amount of time, regardless of whether they are equal or not, ensuring that the comparison is secure and resistant to timing attacks. |

## 3. Set up webhook in RudderStack
Expand Down Expand Up @@ -72,7 +72,7 @@ Access RudderStack Dashboard: Log in to your RudderStack dashboard.
</Step>
<Step>
As a CDP, RudderStack allow your build your own data pipeline. To sink data into RisingWave, you first need to have data sources. You can build your sources following the [guidance](https://www.rudderstack.com/docs/sources/overview/).
Upon you have created your source, in the left sidebar, click on **Collect** > **Destinations** > **New Destination**.
After creating your source, in the left sidebar, click on **Collect** > **Destinations** > **New Destination**.
</Step>
<Step>
Choose Webhook as the Destination:
Expand All @@ -86,8 +86,8 @@ Configure the webhook settings:
- **Webhook URL**: Enter your RisingWave webhook URL.
- **URL Method**: Select `POST`.
- **Headers**: Keep the `content-type: application/json` unchanged. Add an `Authorization` header with the value set to your secret string ('TEST_WEBHOOK' or the secure string you used when creating `test_secret` in RisingWave).
- - Header Key: 'Authorization' (Or replace with the value you like, make sure it's aligned with the `CREATE TABLE` DML SQL)
- - Header Value: 'TEST_WEBHOOK' (replace with your actual secret)
- Header Key: `Authorization` (Or replace with the value you like, make sure it's aligned with the `CREATE TABLE` DML SQL).
- Header Value: `TEST_WEBHOOK` (replace with your actual secret).
</Step>
<Step>
Save and Activate the Destination:
Expand Down
15 changes: 7 additions & 8 deletions integrations/sources/segment-webhook.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,7 @@ CREATE TABLE wbhtable (
| :--------- | :-----------|
| `data JSONB` | Defines the name of column to store the JSON payload from the webhook. Currently, only `JSONB` type is supported for webhook tables. |
| `headers->>'...'` | Extracts the signature provided by Segment in the `x-signature` HTTP header. <br/> <br/> In `secure_compare()` function, the whole HTTP header is interpreted as a JSONB object, and you can access the header value using the `->>` operator, but only the lower-case header names in the `->>` operator, otherwise the verification will fail. |
| encode(...)` | Computes the expected signature. In the example above, it generates an `HMAC SHA-1` hash of the payload (`data`) using the secret (`test_secret`), encodes it in hexadecimal. |
| `encode(...)` | Computes the expected signature. In the example above, it generates an `HMAC SHA-1` hash of the payload (`data`) using the secret (`test_secret`), encodes it in hexadecimal. |
| `secure_compare(...)` | Validates requests by matching the header signature against the computed signature, ensuring only authenticated requests are processed. The `secure_compare()` function compares two strings in a fixed amount of time, regardless of whether they are equal or not, ensuring that the comparison is secure and resistant to timing attacks. |


Expand Down Expand Up @@ -76,19 +76,18 @@ Log in to your Segment workspace.
<Step>
In the left sidebar, click on **Connections** > **Add Destination**.
- Search for `webhook` in the list of available destinations.
- Select **Webhooks (Actions)** and click **Add destination** to proceed to configure it.
- Select **Webhooks (Actions)** and click **Add destination** to proceed.
</Step>
<Step>
- Select data source, which identify the source you want to send events from and follow the steps to name your destination.
- On the **Settings** > **Basic Settings** > **Shared Secret** tab: Enter the same secret string you used when creating the RisingWave
- secret (e.g., `'TEST_WEBHOOK'`). This ensures that Segment signs the payloads using this secret, allowing RisingWave to validate them.
- Check the **Settings** > **Basic Settings** > **Enable Destination** tab and ensure it's enabled.
- Select the data source that identifies the source you want to send events from and follow the steps to name your destination.
- Click on the tab **Settings** > **Basic Settings** > **Shared Secret**, enter the same secret string you used when creating the RisingWave secret (e.g., `'TEST_WEBHOOK'`). This ensures that Segment signs the payloads using this secret, allowing RisingWave to validate them.
- Click on the tab **Settings** > **Basic Settings** > **Enable Destination** and make sure it is enabled.
</Step>
<Step>
Configure the webhook description on the **Mappings** tab.
- Click **New Mapping** and then **Send**.
- Choose the event type you want to send to RisingWave
- Fill the configuration for the webhook requests based on the source information. You can also directly fill the values, filling RisingWave webhook URL as `URL, `POST` as `Method`.
- Choose the event type you want to send to RisingWave.
- Fill the configuration for the webhook requests based on the source information. You can also directly fill the values, filling RisingWave webhook URL as `URL`, `POST` as `Method`.
</Step>
At the end of the page, you can send the test message via **Send test event**.
Review your settings, click **Next** and specify a name.
Expand Down
16 changes: 8 additions & 8 deletions integrations/sources/webhook.mdx
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
title: "Ingest data from webhook"
sidebarTitle: Overview
description: Describes how to ingest data from webhook to RisingWave
description: Describes how to ingest data from webhook to RisingWave.
---

A webhook is a mechanism that enables real-time data transfer between applications by sending immediate notifications when specific events occur. Instead of continuously polling for updates, applications can receive data automatically, making it an efficient way to integrate with third-party services.
Expand Down Expand Up @@ -57,19 +57,19 @@ RisingWave has been verified to work with the following webhook sources and auth
|webhook source|Authentication methods|
| :-- | :-- |
|GitHub| SHA-1 HMAC, SHA-256 HMAC |
|Rudderstack| Bearer Token |
|Segment| SHA-1 HMAC |
|AWS EventBridge| Bearer Token |
|HubSpot| API Key, Signature V2 |
|AWS EventBridge| Bearer Token |
|Rudderstack| Bearer Token |

<Note>While only the above sources have been thoroughly tested, RisingWave can support additional webhook sources and authentication methods. You can integrate other services using similar configurations.</Note>

## See also

Step-by-step guide to help you set up and configure your webhook sources:

[Ingest from Github webhook](/integrations/sources/github-webhook)
[Ingest from Segment webhook](/integrations/sources/segment-webhook)
[Ingest from HubSpot webhook](/integrations/sources/hubspot-webhook)
[Ingest from Amazon EventBridge webhook](/integrations/sources/eventbridge-webhook)
[Ingest from RudderStack webhook](/integrations/sources/rudderstack-webhook)
- [Ingest from Github webhook](/integrations/sources/github-webhook)
- [Ingest from Segment webhook](/integrations/sources/segment-webhook)
- [Ingest from HubSpot webhook](/integrations/sources/hubspot-webhook)
- [Ingest from Amazon EventBridge webhook](/integrations/sources/eventbridge-webhook)
- [Ingest from RudderStack webhook](/integrations/sources/rudderstack-webhook)

0 comments on commit fc8fdf5

Please sign in to comment.