Configuring Webhooks

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. 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	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	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	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	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.

Stripe webhook example showing purchase event data saved to a Zite table

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

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

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 webhookIn chat, describe the webhook source and what the workflow should do with incoming events.

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 URLWhen Zite is ready for a sample event, it shows a webhook URL and waits for the next run. Copy this URL.

Zite waiting for the next webhook run and showing a copyable webhook 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 appOpen 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 eventUse 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 payloadClick 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 workflowOpen 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 appWebhooks created in the editor may show as Not published. Publish the app before relying on the webhook in production.

Confirm events are arrivingTrigger 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.

Webhooks view showing a webhook trigger with its inbound URL

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.

Workflow history filtered to runs triggered by a webhook

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:

Open the app editor.
Go to Workflows.
Open the Webhooks tab.
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

Do I need to write code to create a webhook?

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.

Why does Zite ask me to select an event?

Some platforms send several webhook events for one action. Selecting an event tells Zite which payload shape your workflow should use.

Do webhooks run before the app is published?

Webhooks can be tested in the editor while you are building, but publish the app before relying on them for production events.

Do webhook workflows count as workflow runs?

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.

What happens if the source app sends the same webhook twice?

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.

Getting Started

How to Build

Features

Access & Sharing

Account

API Reference

Security & Legal

How webhooks work

Common webhook examples

Before you start

Create a webhook

Manage webhooks

Troubleshooting

Review a webhook

If the webhook is not working as expected

FAQs

​How webhooks work

​Common webhook examples

​Before you start

​Create a webhook

​Manage webhooks

​Troubleshooting

​Review a webhook

​If the webhook is not working as expected

​FAQs

How webhooks work

Common webhook examples

Before you start

Create a webhook

Manage webhooks

Troubleshooting

Review a webhook

If the webhook is not working as expected

FAQs