
How Webhooks Work in Nekt
Unlike traditional API connectors that pull data from external systems, the Webhook connector receives data that is pushed to an API gateway on your AWS environment. This gateway is responsible for receiving the webhook data and forwarding it to Amazon SQS via lambda. The connector then processes the messages stored on Amazon SQS and loads the data into your catalog. When you configure a Webhook source, Nekt generates a unique URL endpoint. You then configure your external system to send HTTP POST requests to this endpoint whenever relevant events occur.Configuring Webhook as a Source
In the Sources tab, click on the “Add source” button located on the top right of your screen. Then, select the Webhook option from the list of connectors. Click Next and you’ll be prompted to configure your webhook.1. Configure webhook security (optional)
You can protect your webhook endpoint with an API key to ensure only authorized systems can send data:- Webhook API Key: Enable this option if you want to require an API key for incoming requests.
- API Key Header: The HTTP header name where the API key will be sent (e.g.,
x-api-key,Authorization). - API Key Value: The expected value of the API key. Requests without this key (or with an incorrect key) will be rejected.
- API Key Header: The HTTP header name where the API key will be sent (e.g.,
While API key authentication is optional, it’s strongly recommended for production use to prevent unauthorized data from being sent to your webhook endpoint.
2. Get your Webhook URL
After creating the source, Nekt will generate a unique webhook URL for you. This URL is where external systems should send their data.Please ask Nekt support for your webhook URL after the source is created.
3. Configure your external system
Configure your external system, application, or service to send HTTP POST requests to the Nekt webhook URL. The request should:- Use the POST method
- Send data as JSON in the request body
- Include the API key header (if you configured authentication)
- Set
Content-Type: application/json
4. Configure data streams
Customize how you want your data to appear in your catalog. Select the desired layer where the data will be placed, a folder to organize it inside the layer, and a name for the table.- Layer: Choose the layer in your catalog where the webhook data will be stored.
- Folder: Optionally create a folder to organize your webhook data.
- Table name: Name for the table that will contain the webhook events.
The sync type for webhooks is always INCREMENTAL since webhooks are event-driven and each event is a new record.
5. Configure data source
Describe your data source for easy identification within your organization, not exceeding 140 characters. To define your Trigger, consider how often you want the queued webhook data to be processed and loaded into your catalog. Common configurations:- Every 15 minutes: Near real-time processing for time-sensitive data
- Every hour: Balanced approach for most use cases
- Daily: Cost-effective for non-urgent data
6. Check your new source
You can view your new source on the Sources page. Once your external system starts sending webhooks and the extraction trigger runs, your data will appear in your Catalog.Stream and Fields
The Webhook connector provides a single stream that captures all incoming webhook events:| Field | Type | Description |
|---|---|---|
message_id | String | Unique identifier for the webhook message. |
payload | String | The complete JSON payload sent by the external system, stored as a JSON string. |
webhook_received_at | DateTime | Timestamp when Nekt received the webhook. |
The
payload field contains the raw JSON data sent to your webhook. You can parse this field in your SQL queries to extract specific values. See the Use Cases section for examples.Use Cases for Data Analysis
The webhook connector stores your data as a JSON string in thepayload field. Here’s how to extract and analyze your data using SQL.
1. Parse JSON Payload
Extract specific fields from your webhook payload for analysis.SQL query
SQL query
- AWS
- GCP
2. Event Type Distribution
Analyze the distribution of different event types received via webhooks.SQL query
SQL query
- AWS
- GCP
3. Create a Materialized View
For frequently accessed webhook data, consider creating a transformation to parse the payload into structured columns.SQL query (Transformation example)
SQL query (Transformation example)
- AWS
- GCP
Implementation Notes
Data Format
- All webhook data is stored as a JSON string in the
payloadfield - Use your data warehouse’s JSON functions to extract specific fields
- Consider creating transformations to parse frequently accessed data into structured tables
Message Handling
- Each webhook request creates one record in the stream
- Messages are processed incrementally on each extraction run
- The
message_idfield uniquely identifies each webhook event - The
webhook_received_attimestamp reflects when Nekt received the webhook (not when the event occurred in the source system)
Best Practices
- Include timestamps in your payload: Add an
event_timestampor similar field in your webhook payload to track when the event actually occurred in the source system - Use consistent payload structures: Maintain a consistent JSON structure across all webhook events to simplify data parsing
- Include event types: Add an
event_typefield to categorize different types of events - Add idempotency keys: Include a unique identifier in your payload to detect and handle duplicate webhook deliveries
- Test with sample data: Send test webhooks to verify your integration before enabling production webhooks
Troubleshooting
| Issue | Possible Cause | Solution |
|---|---|---|
| No data appearing | Webhook not configured correctly in source system | Verify the webhook URL and test with a sample request |
| 401/403 errors | API key mismatch | Check that the API key header name and value match your configuration |
| Data not updating | Extraction trigger hasn’t run | Check your trigger schedule or manually trigger an extraction |
| Malformed data | Invalid JSON in request body | Ensure your source system sends valid JSON with Content-Type: application/json |