> ## Documentation Index
> Fetch the complete documentation index at: https://docs.risingwave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Ingest data from Segment webhook

> Ingest Segment events directly into your RisingWave database for real-time processing and analytics.

Segment is a Customer Data Platform (CDP) that collects event data from various sources and routes it to different destinations for analytics, marketing, and data warehousing. By configuring a webhook as a destination, you can forward events from Segment directly into RisingWave. This setup enables you to leverage RisingWave’s capabilities for real-time data processing and analytics without the need for additional intermediaries.

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

<Info>
  New to RisingWave webhooks? Before configuring Segment, it's recommended to run a quick local smoke test to confirm your RisingWave webhook listener is reachable and your table is ingesting events. See [Webhook endpoint](/integrations/sources/webhook#webhook-endpoint) and [Quick local smoke test](/integrations/sources/webhook#quick-local-smoke-test-no-upstream-saas-required).
</Info>

## 1. Create a table in RisingWave

Create a table configured to accept webhook data from Segment.

```sql theme={null}
-- Optional (recommended): store the shared secret as a RisingWave secret.
-- If you don't have access to secrets, skip this and use the raw-string example below.
CREATE SECRET test_secret WITH (backend = 'meta') AS 'TEST_WEBHOOK';
```

```sql theme={null}
CREATE TABLE wbhtable (
  data JSONB
) WITH (
  connector = 'webhook',
  [ is_batched = true ]
) VALIDATE SECRET test_secret AS secure_compare(
  headers->>'x-signature',
  encode(hmac(test_secret, data, 'sha1'), 'hex')
);
```

| Parameter or clause   | Description                                                                                                                                                                                                                                                                                                                                        |
| :-------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `data JSONB`          | Defines the name of column to store the JSON payload from the webhook. Currently, only `JSONB` type is supported for webhook tables.                                                                                                                                                                                                               |
| `is_batched`          | Optional, set to `true` to enable batch ingestion of multiple JSON lines in a single request.                                                                                                                                                                                                                                                      |
| `SECRET <secret>`     | Use an existing [secret](/operate/manage-secrets) to verify incoming webhook requests from Segment. This is optional. You can also use a raw string to verify.                                                                                                                                                                                     |
| `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.                                                                                                                                                                      |
| `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.       |

Or you can also use raw string for verification without secret:

```sql theme={null}
CREATE TABLE wbhtable (
  data JSONB
) WITH (
  connector = 'webhook'
) VALIDATE AS secure_compare(
  headers->>'x-signature',
  encode(hmac('TEST_WEBHOOK', data, 'sha1'), 'hex')
);
```

## 2. Set up webhook in Segment

After configuring RisingWave to accept webhook data, set up Segment to send events to your RisingWave instance.

### RisingWave webhook URL

The webhook URL should follow this format:

```
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                                                           |
| `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`.                                           |

### Configure webhook in Segment

For more detailed instructions, refer to the Segment's [Webhooks Destination Documentation](https://segment.com/docs/connections/destinations/catalog/webhooks/) and [Webhooks (Actions) Destination Documentation](https://segment.com/docs/connections/destinations/catalog/actions-webhook/).

<Steps>
  <Step>
    Access the Segment Workspace:\
    Log in to your Segment workspace.
  </Step>

  <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.
  </Step>

  <Step>
    * 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`.
  </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.
</Steps>

## 3. Push data from Segment via webhook

With the webhook configured, Segment will automatically send HTTP POST requests to your RisingWave webhook URL whenever the configured events occur. RisingWave will receive these requests, validate the signatures, and insert the payload data into the target table.

## 4. Further event processing

The data in the table is already ready for further processing. You can access the fields using `data->'field_name'` in SQL queries.

You can create a materialized view to extract specific fields from the JSON payload.

```sql theme={null}
CREATE MATERIALIZED VIEW segmentb_events AS
SELECT
  data->>'action' AS action,
  data->'repository'->>'full_name' AS repository_name,
  data->'sender'->>'login' AS sender_login,
  data->>'created_at' AS event_time
FROM wbhtable;
```

You can now query `segmentb_events` like a regular table to perform analytics, generate reports, or trigger further processing.