> ## Documentation Index
> Fetch the complete documentation index at: https://zite.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Configuring Webhooks
> Use webhooks to trigger Zite workflows when something happens in another app or service.
Use webhooks to:
* Save Stripe payment events to a Zite Database
* Update a dashboard when a customer is created in another system
* Send an email or Slack message when a third-party status changes
* Receive form submissions, order updates, support tickets, or other external events
In Zite, an incoming webhook starts a [workflow](/help/platform/workflows/overview). After the webhook triggers the workflow, Zite can do anything workflows support, such as writing to a database, calling an integration, sending a notification, running AI, or updating data shown in your app.
Webhooks are available on all plans.
## How webhooks work
Most webhook setups have the same parts:
| Part | What it means |
| --------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| **Source app** | The external service that sends the webhook, such as Stripe, Fillout, or another platform. |
| **Event** | The thing that happened in the source app, such as `payment_intent.succeeded` or `form.submitted`. |
| **Webhook URL** | The Zite URL you copy into the source app so it knows where to send events. |
| **Payload** | The JSON data sent with the event. This usually includes IDs, timestamps, status fields, and details about the object that changed. |
| **Workflow** | The Zite backend logic that receives the payload and decides what to do next. |
The source app must support webhooks before Zite can receive them. Larger platforms usually have a webhook setup page where you paste in a destination URL and choose which events to send.
## Common webhook examples
Many popular services can send webhooks or webhook-like push notifications. The exact setup differs by service, but the pattern is the same: paste a Zite webhook URL into the source service, trigger a sample event, then let Zite build a workflow from the captured payload.
| Service | Example events | Example Zite workflow |
| ----------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| [Stripe](https://docs.stripe.com/webhooks) | Customer creation, successful charges, and completed payment intents. | When a customer subscribes or makes a purchase, save the Stripe event data to a Zite Database table so your app can provision access and keep subscription status up to date. |
| [Twilio](https://www.twilio.com/docs/usage/webhooks/webhooks-overview) | Incoming messages, message delivery status changes, and voice call events. | When an SMS arrives or a message delivery status changes, log it in Zite and notify the team. |
| [Slack](https://docs.slack.dev/apis/events-api/) | Workspace events, bot events, mentions, messages, and reactions. | When a message, mention, or reaction event arrives, create a task or support ticket in Zite. |
| [Google Calendar](https://developers.google.com/workspace/calendar/api/guides/push) | Calendar event changes from watchable calendar resources. | When calendar events change, update an internal schedule, booking dashboard, or reminder workflow. |
In this Stripe webhook example, a purchase or subscription event sends Stripe event data to Zite, where the workflow saves the event and can provision access in your app.
Some services need extra setup beyond pasting a URL. For example, Slack may verify your request URL, and Google push notification channels can require renewal and a follow-up API call to fetch the latest data.
## Before you start
Decide what event Zite should listen for and what should happen after it arrives.
Good webhook prompts usually include:
* the source platform
* the event you care about
* where the data should be stored or shown
* which fields matter
* whether the workflow should send notifications or update records
For example:
**Stripe payments**
```text theme={null}
Build an app that receives Stripe webhook events and stores successful
payments in a Zite Database. Track the event ID, payment ID, customer,
amount, currency, status, whether it was live mode, and the raw payload.
Ignore duplicate events with the same Stripe event ID.
```
**Twilio messages**
```text theme={null}
Build an app that receives Twilio webhooks for incoming SMS messages and
message delivery status changes. Store the message SID, phone number,
message body, delivery status, timestamp, and raw payload in Zite Database.
Notify the support team when a message fails to deliver.
```
## Create a webhook
**Ask Zite to create the webhook**
In chat, describe the webhook source and what the workflow should do with incoming events.
```text theme={null}
Create a webhook for Stripe payment events. When a payment succeeds,
save the payment details to the Payments table and update the dashboard.
```
Zite creates a workflow with a webhook trigger. If your app needs somewhere to store the incoming data, Zite may also suggest a database table.
**Copy the webhook URL**
When Zite is ready for a sample event, it shows a webhook URL and waits for the next run. Copy this URL.
This URL is the endpoint the source app will call. Treat it like a public inbound URL and only paste it into services you trust.
**Add the URL to the source app**
Open the webhook settings in the source app, paste the Zite webhook URL, and choose the events you want to send.
For Stripe, this is usually in `Developers` -> `Webhooks`. Other platforms may call this area webhooks, event destinations, callbacks, or HTTP notifications.
Choose only the events your app needs. Sending every available event can make the workflow harder to test and may create unnecessary runs.
**Send a test event**
Use the source app's test tool, or perform the action that should trigger the webhook. For example, in Stripe you can trigger a test payment or customer event.
Zite lists the captured webhook runs. If the source app sends several events for one action, pick the event that best matches what your app should handle.
**Select the event payload**
Click `Use selected event` so Zite can learn the payload shape. This gives Zite the concrete JSON structure it needs to build or update the workflow.
This step is especially useful for smaller platforms where the payload format may not be widely known.
**Review the workflow**
Open the generated workflow to confirm the trigger and actions. A typical webhook workflow might:
* receive the webhook payload
* check whether the event already exists
* extract the fields your app needs
* create or update a database record
* send a notification or update a dashboard
Providers can retry webhooks or send related events close together, so duplicate handling is often important.
**Publish the app**
Webhooks created in the editor may show as `Not published`. Publish the app before relying on the webhook in production.
**Confirm events are arriving**
Trigger another event from the source app, then check the workflow history and any database records or app screens that should update.
## Manage webhooks
Open `Workflows`, then switch the view to `Webhooks` to see webhook triggers in your app.
From this view you can:
* Search for a webhook
* Copy its inbound URL
* See whether it is published
* Enable or disable the webhook
* Add another webhook
* Open the related workflow
Webhook-triggered runs also appear in the workflow's `History` tab. Use history to confirm whether a webhook arrived, whether the workflow succeeded, and which integrations or database actions ran.
## Troubleshooting
If a webhook is not triggering, check:
* The webhook URL in the source app matches the Zite webhook URL
* The source app successfully sent the request
* The source app is sending the event type your workflow expects
* Required fields are included in the payload
* The app is published if you are testing a production webhook
* The webhook and related workflow are enabled
* Any required authentication, permission, or signing settings are configured in the source app
You can review and troubleshoot webhooks directly inside the Zite app editor.
### Review a webhook
To inspect an existing webhook:
1. Open the app editor.
2. Go to `Workflows`.
3. Open the `Webhooks` tab.
4. Click the webhook you want to review.
Inside the webhook, review these tabs:
| Tab | What to check |
| --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `Preview` | Review the webhook trigger, workflow steps, trigger conditions, connected integrations, actions, and overall sequence. This helps confirm the webhook is configured the way you intended. |
| `Code` | Inspect the generated webhook code. If you are comfortable editing code, you can make advanced adjustments to customize, debug, or fine-tune the workflow logic. |
| `History` | Check whether incoming requests were received, whether runs succeeded or failed, what payload data arrived, and where any failed workflow step stopped. |
History is especially useful when testing integrations with services like Stripe, Fillout, Zapier, Make, or other tools that send webhook requests.
### If the webhook is not working as expected
If the webhook runs but the behavior does not match what you intended, use Chat mode to ask Zite for help.
Describe:
* What is currently happening
* What you expected to happen instead
* Any error messages from the `History` tab
* A sample payload or relevant field names, if available
Chat mode can inspect your app's code and workflow configuration, identify likely issues, suggest fixes, and help adjust the workflow logic. In many cases, Zite can update the webhook setup based on your description.
## FAQs
No. You can describe the webhook and the action you want in chat. Zite creates the webhook-triggered workflow and can use a captured sample payload to understand the incoming data.
Some platforms send several webhook events for one action. Selecting an event tells Zite which payload shape your workflow should use.
Webhooks can be tested in the editor while you are building, but publish the app before relying on them for production events.
Yes. A webhook starts a workflow, so successful runs from a published app count as workflow runs like other published workflow executions. Editor test runs do not count.
Your workflow should use a stable event ID from the source app to detect duplicates. Zite can usually add this automatically when the prompt and payload make the ID clear, but it is worth asking for duplicate handling explicitly.
Related topics