Skip to main content
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. RisingWave can serve as a webhook destination, directly accepting HTTP requests from external services and storing the incoming data in its tables. By default, the frontend node listens for webhook events on port 4560. You can reconfigure this depending on how your cluster is deployed. When a webhook is triggered, RisingWave processes and ingests the data in real-time. This direct integration eliminates the need for an intermediary message broker like Kafka. Instead of setting up and maintaining an extra Kafka cluster, you can directly send data to RisingWave to process it in real-time, which enables efficient data ingestion and stream processing without extra infrastructure.
Looking for a standalone HTTP service to ingest app events (JSON/NDJSON) into RisingWave, or to execute SQL over HTTP? See Events API.

​
Creating a webhook table in RisingWave

To utilize webhook sources in RisingWave, you need to create a table configured to accept webhook requests. If you’re new to webhooks, start with the local smoke test below (no upstream SaaS required). Once your endpoint works end-to-end, pick one of the validation options (secret vs raw string) based on your subscription and security requirements.

​
Webhook endpoint

Webhook requests should be sent to: http://<HOST>:4560/webhook/<database>/<schema>/<table> The default listening port is 4560. Replace <schema> with public if you didn’t create the table under a custom schema.

​
Quick local smoke test (no upstream SaaS required)

If you can access RisingWave’s webhook listener and SQL endpoint (for example, via local deployment or port-forwarding), you can do a quick end-to-end test with curl:
  1. Create a demo table that accepts requests with header signature: 1 (a minimal local-test validation; replace with real signature/HMAC validation for production).
CREATE TABLE wbhtable (
  data JSONB
) WITH (
  connector = 'webhook'
) VALIDATE AS secure_compare(
  headers->>'signature',
  '1'
);
  1. Send one event to RisingWave.
# Replace localhost/dev/public/wbhtable with your HOST/DB/SCHEMA/TABLE.
curl -v -X POST http://localhost:4560/webhook/dev/public/wbhtable \
  -H "Content-Type: application/json" \
  -H "signature: 1" \
  -d '{"event":"user.signup","data":{"user_id":"123"}}'
  1. Query the table to verify ingestion.
SELECT * FROM wbhtable;
RisingWave supports validating incoming webhook requests using secure_compare(...). You can either store your shared key as a RisingWave secret, or embed it directly as a SQL string literal.
Secret management is a premium feature. If you don’t have access to secrets, use Option B (SQL string literal) instead.

​
Option A: use a RisingWave secret

-- Create a secret to store the shared key.
CREATE SECRET test_secret WITH (backend = 'meta') AS 'TEST_WEBHOOK';

CREATE TABLE wbhtable (
  data JSONB
) WITH (
  connector = 'webhook'
) VALIDATE SECRET test_secret AS secure_compare(
  headers->>'authorization',
  test_secret
);

​
Option B: use a SQL string literal (raw string)

CREATE TABLE wbhtable (
  data JSONB
) WITH (
  connector = 'webhook'
) VALIDATE AS secure_compare(
  headers->>'authorization',
  'TEST_WEBHOOK'
);
In headers->>'...', always use the lower-case header name (for example, authorization). If you use a different casing, validation may fail.
For providers that sign payloads (for example, GitHub/Segment), the second argument of secure_compare(...) is typically an expression that computes the expected signature from the secret/raw string and the request body (data). See the provider-specific guides below for copy/paste-ready examples.

​
Supported webhook sources and authentication methods

RisingWave has been verified to work with the following webhook sources and authentication methods:
webhook sourceAuthentication methods
GitHubSHA-1 HMAC, SHA-256 HMAC
SegmentSHA-1 HMAC
HubSpotAPI Key, Signature V2
AWS EventBridgeBearer Token
RudderstackBearer Token
Here are step-by-step guides to help you set up and configure your webhook sources:
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.

​
Deploy RisingWave webhook listener

Learn how to deploy and test RisingWave’s webhook listener using open-source tools such as Kubernetes Operator and Helm Chart.

​
Kubernetes operator

Make sure risingwave-operator ≥ v0.12.0.
  1. Prepare a YAML manifest of RisingWave with the following field set: 
    apiVersion: risingwave.risingwavelabs.com/v1alpha1
kind: RisingWave
metadata:
  name: risingwave
spec:
  enableWebhookListener: true
    You can try with the base YAML.
  2. Apply the YAML to create the RisingWave instance.
Endpoint (intra-Kubernetes) Depending on the object name and namespace, the endpoint is typically: 
Example: risingwave-frontend.default.svc.cluster.local:4560
Format: <service name>.<namespace>.svc.<cluster domain>:4560

​
Helm Chart

Make sure Helm chart ≥ 0.2.38.
  1. Prepare a YAML values of RisingWave with the following field set: 
    frontendComponent:
  webhookListener: true
  2. Install a Helm release with the values.
    Example command
    helm install --set tags.bundle=true,frontendComponent.webhookListener=true risingwave risingwavelabs/risingwave --version 0.2.38
Endpoint (intra-Kubernetes) Depending on the release name and namespace, the endpoint is typically: 
Example: risingwave.default.svc.cluster.local:4560
Format: <service name>.<namespace>.svc.<cluster domain>:4560

​
Test webhook locally using Helm

To test the webhook locally using Helm, first install a Helm release using the example command provided in Helm Chart. Once the Helm release is running, follow these steps:
  1. Forward ports of the RisingWave to local 
    kubectl port-forward svc/risingwave 4560,4567
  2. Connect with psql and create a demo table. 
    psql -h localhost -p 4567 -d dev -U root
dev=> CREATE TABLE wbhtable (
  data JSONB
) WITH (
  connector = 'webhook'
) VALIDATE AS secure_compare (
  headers->>'signature',
  '1'
);
CREATE_TABLE
  3. Send sample data with curl 
    curl -v -X POST http://localhost:4560/webhook/dev/public/wbhtable \
              -H "Content-Type: application/json" \
              -H "signature: 1" \
              -d '{
        "event": "user.signup",
        "timestamp": "2025-10-10T08:30:00Z",
        "data": {
          "user_id": "12345",
          "email": "[email protected]",
          "name": "John Doe"
        }
      }'
  4. Query from the table and check the result. 
    psql -h localhost -p 4567 -d dev -U root
dev=> select * from wbhtable;
                                                                     data
----------------------------------------------------------------------------------------------------------------------------------------------
 {"data": {"email": "[email protected]", "name": "John Doe", "user_id": "12345"}, "event": "user.signup", "timestamp": "2025-10-10T08:30:00Z"}
(1 row)