
How Webhooks Work in Nekt
When you create a Webhook source, Nekt provisions a unique URL endpoint on your cloud infrastructure. You configure your external system to send HTTP POST requests to that URL whenever a relevant event occurs. Incoming events are not processed immediately. Instead, each request is stored in a queue. When the source runs — triggered manually, on a schedule, or by an event — it processes all queued events and loads them into the Catalog. This means no events are missed between runs: everything sent to the endpoint is held in the queue until the next extraction.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 settings
You can protect your webhook endpoint with an API key to ensure only authorized systems can send data. You can also define how the connector interprets the incoming JSON payloads:- 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.,
- Use payload schema template: (Default:
false) If enabled, each message is projected into typed columns (with dynamic type inference) instead of wrapping the whole body into a singlepayloadcolumn. The following options apply only when this is enabled:- Save payload as JSON string (Advanced): (Default:
false) If enabled, each message is stored whole as a JSON string in a singlepayloadcolumn instead of being projected into typed columns. Use this when the producer sends a different shape per event type, or keeps adding fields inside nested objects: those changes cannot be applied to an existing nested column and break the sync. Takes precedence over the fixed schema and disables schema inference. - Payload records JSONPath: (Default:
$) JSONPath evaluated against each message body to extract record(s). The default$emits the whole body as one record. Use$.records[*]to fan a single envelope into one row per item, or$.datato unwrap a sub-object. - Primary keys: The primary keys that should be used to uniquely identify each message. Note that if Save payload as JSON string is enabled, keys referencing fields inside the payload are ignored; use
_nekt_message_idto keep rows deduplicated. - Fixed schema (JSON file): Optional. Upload a JSON file with a Singer schema (e.g.,
{"type": "object", "properties": {"id": {"type": ["string", "null"]}}}) to pin the column types instead of inferring them from the messages. This is recommended whenever the producer isn’t strict about types: inference only looks at a sample, so a field that arrives as"123"in one message and123in the next can change type between runs and break the destination. The_nekt_*metadata columns are added automatically. When set, schema inference is skipped entirely. - Number of messages to infer the schema: (Default:
10) Dictates how many messages to sample when inferring column types. Sampling more messages makes the inferred types more accurate: a field seen with conflicting scalar types across the sample becomes a string instead of changing type between runs. This setting is ignored when a fixed schema is uploaded.
- Save payload as JSON string (Advanced): (Default:
- Delete messages: (Default:
false) Mark as true if you want messages to be deleted (SQS) or acknowledged (Pub/Sub) after processing.
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. To get it, open your source from the Sources page. The Webhook URL is shown on the Details tab, and you can click Copy next to it to copy it to your clipboard. No need to request it from Nekt support.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, a name for the table (which will effectively contain the fetched data) and the type of sync.- Layer: choose between the existing layers on your catalog. This is where you will find your new extracted tables as the extraction runs successfully.
- Folder: a folder can be created inside the selected layer to group all tables being created from this new data source.
- Table name: we suggest a name, but feel free to customize it. You have the option to add a prefix to all tables at once and make this process faster!
- Sync Type: you can choose between INCREMENTAL and FULL_TABLE. For webhooks, the sync type 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 Nekt. 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
- Configure Delta Log Retention and determine for how long we should store old states of this table as it gets updated. Read more about this resource here.
6. Check your new source
You can view your new source on the Sources page. If needed, manually trigger the source extraction by clicking on the arrow button. Once your external system starts sending webhooks and the extraction runs, your data will appear in your Catalog.Streams and Fields
The Webhook connector can capture incoming webhook events either as raw JSON payloads or as parsed, strongly-typed columns depending on your configuration:Raw Payload Stream (Default)
Raw Payload Stream (Default)
Captures all incoming webhook events as a single stream with the raw data stored in a JSON string field.
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.Parsed Payload Stream
Parsed Payload Stream
When you enable Use payload schema template, every top-level field of each matched JSON record (extracted via the Payload records JSONPath) becomes its own column. Column types come from one of two places:
- The explicit Fixed schema (JSON file), if provided.
- Inference over a sample of messages peeked from the queue. (A field seen with conflicting scalar types across the sample collapses to a
string).
(All other columns will dynamically match the fields in your JSON payload based on the fixed schema or inference)
If you enable the advanced Save payload as JSON string option, the dynamic projection is bypassed. Instead, each extracted record is stored whole as a JSON string in a single
payload column, alongside the two metadata columns above. This effectively protects against a source with continually changing schemas or deeply nested fields.Use Cases for Data Analysis
If you are using the raw payload stream, 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
- If using the default raw payload, all webhook data is stored as a JSON string in the
payloadfield. Use your data warehouse’s JSON functions to extract specific fields, or consider creating transformations to parse frequently accessed data into structured tables. - If using payload schema extraction, JSON fields are mapped directly to table columns. A field seen with conflicting scalar types during inference (e.g., an integer in one message and a string in the next) will be automatically cast to a
stringtype to prevent data coercion failures. Alternatively, enable Save payload as JSON string to bypass column projection and store each extracted record safely as a full JSON string in a singlepayloadcolumn.
Message Handling
- Each webhook request creates one record in the stream.
- Messages are processed incrementally on each extraction run.
- For raw payloads, the
message_idfield uniquely identifies each webhook event, andwebhook_received_atreflects when Nekt received the webhook (not when the event occurred in the source system). - For parsed payloads, the metadata columns
_nekt_message_idand_nekt_webhook_received_atserve these same purposes. - When performing schema inference, the connector temporarily peeks at messages in the queue without consuming them, keeping them available to be processed normally during the actual sync.
Cloud Provider Infrastructure
Nekt automatically handles the underlying queue backend for your webhooks depending on your deployment’s cloud provider (AWS SQS or GCP Pub/Sub). Thecloud_provider configuration is a hidden requirement fixed securely by your environment. This ensures that orchestrators and agents can implicitly provision and map the correct resources without requiring any manual setup on your end.
Best Practices
- Provide a Fixed Schema: If your external system tends to send mixed types for the same field, upload a fixed schema JSON file to enforce strict structure and avoid flapping schema definitions between runs.
- Use JSON String Fallback: If the producer sends a completely different shape per event type or continually adds fields inside nested objects, enable Save payload as JSON string to prevent nested column errors and schema breakage.
- 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
Skills for agents
Download Webhook skills file
Webhook connector documentation as plain markdown, for use in AI agent contexts.