# Store webhook requests in a database

Receive an event and insert a request record into a selected Chatigram table, with destination mappings supplied during setup.

## Plan availability

| Feature | Free | Starter | Pro | Enterprise |
| --- | --- | --- | --- | --- |
| Databases | Not included | 1 | 2 | Unlimited |
| Active workflows | 3 | 10 | 45 | Unlimited |

Allowances follow the [published Chatigram pricing page](https://chatigram.com/pricing/). Your organization’s Billing & Plans screen confirms its subscription and current usage. Plans can change. Plan information reviewed 2026-11-10.


## The business outcome

Receive an event and insert a request record into a selected Chatigram table, with destination mappings supplied during setup.

This is an importable starter using Chatigram’s current native nodes. It needs destination-specific setup; it does not imply a dedicated connector for every CRM or ERP brand. Check your software’s API documentation and permissions.

## Before you begin

Set a fresh webhook secret, select the database/table, map request fields to columns, and configure the sending service. An empty values list must be mapped before use.

The reserved example.invalid endpoint is deliberately non-working. No real customer data, account credentials, or private resource identifiers are embedded. Keep the workflow disabled until setup is complete.

## Configure the workflow

1. Prepare a request table with the fields your process actually needs, such as external event ID, request text, and processing state.
2. Configure the Webhook trigger’s protected request details in the sending service. The whole payload is available as trigger.payload; add field extractors for individual values.
3. Select the destination table in saveRequest and map the required fields using the variable picker. The starter intentionally has no column IDs or value mappings.
4. Preserve an external event identifier and design a duplicate check if the sender can retry the same event.

## Test the outcomes

- Send one harmless test event and inspect the created record.
- Test the sender’s repeated-delivery behavior before enabling real intake.
- Verify that only the needed fields are stored.

Open [Workflow Activity](/workflows/activity/) after the test. Import validation checks the definition; it does not prove a remote API accepted the business operation. Check the destination before repeating a send or write.

## Make it your own

Put reusable public settings in [Properties](/workflows/properties/), configure credentials through the protected connection options, and keep explicit error paths. Explore [App Connections](/integrations/overview/) for existing provider-specific actions you can substitute through the editor.

Use the copy controls below for the complete workflow or its first node. The diagram and downloads come from the same definition. Use Share recipe to share the guide’s public address.


## Copyable workflow

https://docs.chatigram.com/examples/webhook-request-inbox.json