> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dodopayments.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Webhooks
> Receive real-time notifications when events occur in Dodo Payments. Automate workflows and keep your systems synchronized with instant event delivery.
Webhooks provide real-time notifications when specific events occur in your Dodo Payments account. Use webhooks to automate workflows, update your database, send notifications, and keep your systems synchronized.
Our webhook implementation follows the [Standard Webhooks](https://standardwebhooks.com/) specification, ensuring compatibility with industry best practices and existing webhook libraries.
## Key Features
Receive instant notifications when events occur
HMAC SHA256 signature verification included
Built-in retry logic with exponential backoff
Subscribe only to events you need
## Getting Started
The Dodo Payments webhooks portal has been rebuilt with a native dashboard experience. Your existing endpoints, signing secrets, signature verification, event names, and webhook payloads are unchanged. No integration work is needed.
**Where things live.**
* **Under Developer → Webhooks** — the **Endpoints**, **Event catalog**, **Logs**, **Activity**, and **Settings** tabs.
* **On an individual endpoint** — the **Overview** tab, carrying delivery stats, the signing secret and **Replay history**, plus the **Testing** and **Advanced** tabs and the bulk replay actions.
* **On a message** — opened from the **Logs** tab, where each delivery attempt can be replayed on its own without opening the endpoint.
Navigate to the Dodo Payments Dashboard and go to **Developer → Webhooks**.
Click **Add endpoint** to open the endpoint creation side sheet.
Enter the URL where you want to receive webhook events, or select an integration connector to route events to a third-party service (Slack, Discord, Zapier, Resend, etc.).
Choose the specific events your endpoint should listen for. Events are organized in a searchable tree grouped by resource. You can select individual events or a parent resource to receive all related events.
Only selected events will trigger webhooks to your endpoint, helping you avoid unnecessary traffic and processing.
Click **Create endpoint** to save your configuration.
Your webhook signing secret is displayed on the endpoint's **Overview** tab. You'll use this to verify the authenticity of received webhooks.
Keep your webhook secret key secure and never expose it in client-side code or public repositories.
If needed, you can rotate your webhook secret for enhanced security. Click **Rotate secret**, alongside the secret on the **Overview** tab.
Rotating the secret will expire it and replace it with a new one. The old secret will only be valid for the next 24 hours. Afterward, trying to verify with the old secret will fail.
Use secret rotation periodically or immediately if you suspect your current secret has been compromised.
## Integration Connectors
Instead of building your own webhook receiver, you can route webhook events directly to third-party services using integration connectors. This eliminates the need to write and maintain custom webhook handlers for popular platforms.
### How Connectors Work
A connector carries a transformation that converts the Dodo Payments event into the shape the destination expects. Which details you supply depends on the destination:
| Connector type | What you provide | Destinations |
| ------------------------ | ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Incoming webhook URL** | A webhook URL you create in the vendor's own dashboard. No API key. | [Slack](/integrations/slack), [Discord](/integrations/discord), [Microsoft Teams](/integrations/microsoft-teams), [Zapier](/integrations/zapier), [Windmill](/integrations/windmill) |
| **Vendor API** | An API key. The destination URL comes from the connector template. | [Resend](/integrations/resend), [SendGrid](/integrations/sendgrid), [Segment](/integrations/segment), [Customer.io](/integrations/customer-io), [HubSpot](/integrations/hubspot), [Close CRM](/integrations/close-crm), [Loops](/integrations/loops) |
The connector picker in the dashboard shows the full set currently available to your business, so treat the table above as the destinations with step-by-step setup instructions rather than an exhaustive list. See [External Integrations](/integrations/introduction) for what each destination can do once events reach it.
### Setting Up a Connector
Pick a connector while creating or editing an endpoint, and the side sheet shows setup instructions written for that destination — for example, how to create an incoming webhook URL in Slack, or where to find your Resend API key. Before you save, run the connector transformation test to confirm the event is converted correctly for the destination.
Use a connector to reach a supported destination without writing code. If you need custom logic, use a standard endpoint with a [transformation](#transformations) instead.
## Configuring Subscribed Events
You can configure which specific events each webhook endpoint should receive.
Go to your Dodo Payments Dashboard and navigate to **Developer → Webhooks**.
Click on the webhook endpoint you want to configure.
Click **Edit** to open the endpoint configuration side sheet.
The event type selector displays all available webhook events organized in a searchable tree, grouped by resource (e.g., `payment`, `subscription`, `dispute`). Use the search bar to quickly find specific events by name or keyword.
Check the boxes next to the events you want to receive. You can:
* Select individual events (e.g., `payment.succeeded`, `payment.failed`)
* Select a parent resource to receive all related events
* Mix and match specific events based on your needs
Click **Save** to apply your changes, or **Cancel** to discard modifications.
If you deselect all events, your webhook endpoint will not receive any notifications. Make sure to select at least the events your application needs to function properly.
## Event Catalog
Go to **Developer → Webhooks** and open the **Event catalog** tab. It lists every event type Dodo Payments can send, so you can see what is available before subscribing an endpoint to it. Select an event to view its schema and an example payload, which is the quickest way to check the shape of a field you plan to read.
Browse the same events as reference documentation, grouped by resource.
## Webhook Delivery
### Timeouts
Webhooks have a **15-second timeout window** for both connection and read operations. Ensure your endpoint responds quickly to avoid timeouts.
Process webhooks asynchronously by acknowledging receipt immediately with a `200` status code, then handling the actual processing in the background.
### Automatic Retries
If a webhook delivery fails, Dodo Payments automatically retries with exponential backoff to prevent overwhelming your system.
| Attempt | Delay | Description |
| ------- | ----------- | ------------------------------------------------------------ |
| 1 | Immediately | First retry happens right away |
| 2 | 5 seconds | Second attempt after short delay |
| 3 | 5 minutes | Third attempt with increased backoff |
| 4 | 30 minutes | Fourth attempt continuing backoff |
| 5 | 2 hours | Fifth attempt with extended delay |
| 6 | 5 hours | Sixth attempt with longer delay |
| 7 | 10 hours | Seventh attempt with maximum delay |
| 8 | 10 hours | **Final attempt** - webhook marked as failed if unsuccessful |
**Maximum of 8 retry attempts** per webhook event. For example, if a webhook fails three times before succeeding, the total delivery time is approximately 35 minutes and 5 seconds from the first attempt.
Use the Dodo Payments dashboard to manually retry individual messages or bulk recover all failed messages at any time.
### Idempotency
Each webhook event includes a unique `webhook-id` header. Use this identifier to implement idempotency and prevent duplicate processing.
```javascript theme={null}
// Example: Storing webhook IDs to prevent duplicate processing
const processedWebhooks = new Set();
app.post('/webhook', (req, res) => {
const webhookId = req.headers['webhook-id'];
if (processedWebhooks.has(webhookId)) {
return res.status(200).json({ received: true });
}
processedWebhooks.add(webhookId);
// Process the webhook...
});
```
Always implement idempotency checks. Due to retries, you may receive the same event multiple times.
### Event Ordering
Webhook events may arrive out of order due to retries or network conditions. Design your system to handle events in any sequence.
You will receive the **latest payload at the time of delivery**, regardless of when the webhook event was originally emitted.
## Securing Webhooks
To ensure the security of your webhooks, always validate the payloads and use HTTPS.
### Verifying Signatures
Each webhook request includes a `webhook-signature` header, an HMAC SHA256 signature of the webhook payload and timestamp, signed with your secret key.
#### SDK verification (recommended)
All official SDKs include built‑in helpers to securely validate and parse incoming webhooks. Two methods are available:
* `unwrap()`: Verifies signatures using your webhook secret key
* `unsafe_unwrap()`: Parses payloads without verification
Provide your webhook secret via `DODO_PAYMENTS_WEBHOOK_KEY` when initializing the Dodo Payments client.
```typescript TypeScript/Node.js theme={null}
import DodoPayments from 'dodopayments';
import express from 'express';
const app = express();
app.use(express.raw({ type: 'application/json' }));
const client = new DodoPayments({
bearerToken: process.env.DODO_PAYMENTS_API_KEY,
environment: process.env.DODO_PAYMENTS_ENVIRONMENT,
webhookKey: process.env.DODO_PAYMENTS_WEBHOOK_KEY,
});
app.post('/webhook', async (req, res) => {
try {
const unwrapped = client.webhooks.unwrap(req.body.toString(), {
headers: {
'webhook-id': req.headers['webhook-id'] as string,
'webhook-signature': req.headers['webhook-signature'] as string,
'webhook-timestamp': req.headers['webhook-timestamp'] as string,
},
});
res.json({ received: true });
} catch (error) {
res.status(401).json({ error: 'Invalid signature' });
}
});
```
```python Python theme={null}
from fastapi import FastAPI, Request, HTTPException
from dodopayments import DodoPayments
import os
app = FastAPI()
client = DodoPayments(
bearer_token=os.getenv("DODO_PAYMENTS_API_KEY"),
environment=os.getenv("DODO_PAYMENTS_ENVIRONMENT"),
webhook_key=os.getenv("DODO_PAYMENTS_WEBHOOK_KEY"),
)
@app.post("/webhook")
async def handle_webhook(request: Request):
try:
unwrapped = client.webhooks.unwrap(
await request.body(),
headers={
"webhook-id": request.headers.get("webhook-id", ""),
"webhook-signature": request.headers.get("webhook-signature", ""),
"webhook-timestamp": request.headers.get("webhook-timestamp", ""),
},
)
return {"received": True}
except Exception:
raise HTTPException(status_code=401, detail="Invalid signature")
```
```go Go theme={null}
import (
"context"
"io"
"net/http"
"os"
"github.com/dodopayments/dodopayments-go"
"github.com/dodopayments/dodopayments-go/option"
)
func webhookHandler(w http.ResponseWriter, r *http.Request) {
client := dodopayments.NewClient(
option.WithBearerToken(os.Getenv("DODO_PAYMENTS_API_KEY")),
option.WithEnvironment(os.Getenv("DODO_PAYMENTS_ENVIRONMENT")),
option.WithWebhookKey(os.Getenv("DODO_PAYMENTS_WEBHOOK_KEY")),
)
rawBody, _ := io.ReadAll(r.Body)
if _, err := client.Webhooks.Unwrap(context.Background(), rawBody, map[string]string{
"webhook-id": r.Header.Get("webhook-id"),
"webhook-signature": r.Header.Get("webhook-signature"),
"webhook-timestamp": r.Header.Get("webhook-timestamp"),
}); err != nil {
http.Error(w, "Invalid signature", http.StatusUnauthorized)
return
}
w.WriteHeader(http.StatusOK)
}
```
#### Manual verification (alternative)
If you are not using an SDK, you can verify signatures yourself following the Standard Webhooks spec:
1. Build the signed message by concatenating `webhook-id`, `webhook-timestamp`, and the exact raw stringified `payload`, separated by periods (`.`).
2. Compute the HMAC SHA256 of that string using your webhook secret key from the Dashboard.
3. Compare the computed signature to the `webhook-signature` header. If they match, the webhook is authentic.
We follow the Standard Webhooks specification. You can use their libraries to verify signatures: [https://github.com/standard-webhooks/standard-webhooks/tree/main/libraries](https://github.com/standard-webhooks/standard-webhooks/tree/main/libraries). For event payload formats, see the [Webhook Payload](/developer-resources/webhooks/intents/payment).
### Source IP Addresses
Signature verification is the supported way to authenticate a webhook. It proves the request was signed with your webhook secret, which a network-level check cannot do.
Webhook deliveries are sent from a pool of source IP addresses belonging to our delivery infrastructure. That pool changes from time to time, so treat the addresses as operational detail rather than a fixed property of the integration.
Do not use a source IP allowlist as your authentication mechanism. An allowlist only shows where a request came from, not that it is genuine or unmodified — verify the `webhook-signature` header on every request, as described in [Verifying Signatures](#verifying-signatures).
If your infrastructure sits behind a firewall that requires an explicit allowlist, keep the following in mind:
* **Do not hardcode addresses permanently.** Ranges are added and retired over time, and a stale rule silently blocks deliveries.
* **Request the current ranges** from [support@dodopayments.com](mailto:support@dodopayments.com) before you lock down a firewall, so you are working from an up-to-date list.
* **Watch for change notices.** When delivery addresses change, we notify affected merchants by email — apply those updates before the stated date to avoid dropped deliveries.
* **Keep signature verification enabled** regardless of any network rules you add.
On serverless and managed hosting platforms, inbound IP filtering is often unavailable or impractical to maintain. Signature verification is the correct control in those environments, and no allowlist is required.
A blocked delivery is treated the same as any other failure and is retried on the schedule described in [Automatic Retries](#automatic-retries). If firewall rules caused deliveries to fail, you can re-send them once the rules are fixed — see [Replaying and Recovering Messages](#replaying-and-recovering-messages).
### Responding to Webhooks
* Your webhook handler must return a `2xx status code` to acknowledge receipt of the event.
* Any other response will be treated as a failure, and the webhook will be retried.
### Best Practices
Always use HTTPS URLs for webhook endpoints. HTTP endpoints are vulnerable to man-in-the-middle attacks and expose your webhook data.
Return a `200` status code immediately upon receiving the webhook. Process the event asynchronously to avoid timeouts.
```javascript theme={null}
app.post('/webhook', async (req, res) => {
// Acknowledge receipt immediately
res.status(200).json({ received: true });
// Process asynchronously
processWebhookAsync(req.body).catch(console.error);
});
```
Implement idempotency using the `webhook-id` header to safely process the same event multiple times without side effects.
Store your webhook secret securely using environment variables or a secrets manager. Never commit secrets to version control.
## Webhook Payload Structure
Understanding the webhook payload structure helps you parse and process events correctly.
### Request Format
```http theme={null}
POST /your-webhook-url
Content-Type: application/json
```
### Headers
Unique identifier for this webhook event. Use this for idempotency checks.
HMAC SHA256 signature for verifying the webhook authenticity.
Unix timestamp (in seconds) when the webhook was sent.
### Request Body
Your Dodo Payments business identifier.
Event type that triggered this webhook (e.g., `payment.succeeded`, `subscription.active`).
ISO 8601 formatted timestamp of when the event occurred.
Event-specific payload containing detailed information about the event.
Type of resource. One of: `Payment`, `Subscription`, `Refund`, `Dispute`, `LicenseKey`, `CreditLedgerEntry`, `CreditBalanceLow`, `AbandonedCheckout`, `DunningAttempt`, `EntitlementGrant`, or `Payout`.
Additional fields vary by event type. See the event-specific documentation for complete schemas.
### Example Payload
```json theme={null}
{
"business_id": "string",
"type": "payment.succeeded | payment.failed |...",
"timestamp": "2024-01-01T12:00:00Z",
"data": {
"payload_type": "Payment | Subscription | Refund | Dispute | LicenseKey | CreditLedgerEntry | CreditBalanceLow | AbandonedCheckout | DunningAttempt | EntitlementGrant | Payout",
// ... event-specific fields (see below)
}
}
```
Browse all available webhook event types
View detailed payload schemas for each event
React to `payment.failed` and recover declined payments
## Testing Webhooks
You can test your webhook integration directly from the Dodo Payments dashboard to ensure your endpoint is working correctly before going live.
Go to your Dodo Payments Dashboard and navigate to **Developer → Webhooks**.
Click on your webhook endpoint to access its details page.
Click on the **Testing** tab to access the webhook testing interface.
### Send an Example Event
The **Testing** tab dispatches a sample payload to this endpoint so you can verify your receiver.
Use **Select an event type** to choose the event you want to test, for example `payment.succeeded` or `payment.failed`.
Click **Send example**. The sample payload is delivered to your endpoint URL exactly like a real event, signed the same way.
Failed messages sent from the Testing tab are not retried. Use it to verify your receiver, not to test the retry schedule.
The tab records when the **Last example sent** went out. Confirm the event arrived, that your signature verification passed, and that you returned a `2xx` status code.
### Implementation Example
Here's a complete Express.js implementation showing webhook verification and handling:
```typescript Express.js Webhook Handler theme={null}
import { Webhook } from "standardwebhooks";
import express from "express";
const app = express();
app.use(express.json());
const webhook = new Webhook(process.env.DODO_WEBHOOK_SECRET);
app.post('/webhook/dodo-payments', async (req, res) => {
try {
// Extract webhook headers
const webhookHeaders = {
"webhook-id": req.headers["webhook-id"] as string,
"webhook-signature": req.headers["webhook-signature"] as string,
"webhook-timestamp": req.headers["webhook-timestamp"] as string,
};
// Verify the webhook signature
const payload = JSON.stringify(req.body);
await webhook.verify(payload, webhookHeaders);
// Acknowledge receipt immediately
res.status(200).json({ received: true });
// Process webhook asynchronously
processWebhookAsync(req.body).catch(console.error);
} catch (error) {
console.error('Webhook verification failed:', error);
res.status(400).json({ error: 'Invalid signature' });
}
});
async function processWebhookAsync(data: any) {
// Handle the webhook event based on type
switch (data.type) {
case 'payment.succeeded':
await handlePaymentSucceeded(data);
break;
case 'subscription.active':
await handleSubscriptionActive(data);
break;
// Add more event handlers...
}
}
```
```javascript Testing Webhooks Locally theme={null}
const { Webhook } = require("standardwebhooks");
const axios = require("axios");
const crypto = require("crypto");
// Generate test webhook
const timestamp = new Date();
const webhookId = crypto.randomUUID();
const payload = {
business_id: "biz_test123",
type: "payment.succeeded",
timestamp: timestamp.toISOString(),
data: {
payload_type: "Payment",
payment_id: "pay_test456",
amount: 2999
}
};
// Sign the payload
const webhookSecret = process.env.DODO_WEBHOOK_SECRET;
const webhookInstance = new Webhook(webhookSecret);
const payloadString = JSON.stringify(payload);
const signature = webhookInstance.sign(webhookId, timestamp, payloadString);
// Send test webhook
const response = await axios.post('http://localhost:3000/webhook/dodo-payments', payload, {
headers: {
"webhook-id": webhookId,
"webhook-timestamp": Math.floor(timestamp.getTime() / 1000),
"webhook-signature": signature,
"Content-Type": "application/json"
}
});
console.log("Test webhook sent successfully:", response.data);
```
Test your webhook handler thoroughly using the dashboard testing interface before processing production events. This helps identify and fix issues early.
## Testing Webhooks with the CLI
The [Dodo Payments CLI](/developer-resources/sdks/cli) provides two commands for testing webhooks during local development, without needing to leave your terminal.
### Listen for Live Webhooks Locally
Forward real webhook events from your test mode account to your local development server in real time:
```bash theme={null}
dodo wh listen
```
The CLI opens a WebSocket connection to Dodo Payments and forwards every webhook event to your local endpoint (e.g., `http://localhost:3000/webhook`), preserving all headers including signature headers for verification testing.
The listener only works with **test mode** API keys. Run `dodo login` and select Test Mode before using this command.
### Trigger Mock Webhook Events
Send mock webhook payloads to any endpoint without creating real transactions:
```bash theme={null}
dodo wh trigger
```
This interactive tool lets you pick an event type and sends a realistic mock payload to your endpoint. It loops so you can test multiple events in one session.
The trigger command covers all 47 event types Dodo Payments delivers, including the subscription, payment, refund, dispute, license key, payout, credit, abandoned checkout, dunning, and entitlement grant families — see [Supported Webhook Events](/developer-resources/sdks/cli#supported-webhook-events) for the exact list.
Mock webhook payloads from `dodo wh trigger` are not signed. Use `unsafe_unwrap()` instead of `unwrap()` in your webhook handler during testing only.
See the full CLI webhook testing documentation
## Advanced Settings
The **Advanced** tab provides additional configuration options for fine-tuning your webhook endpoint behavior.
### Rate Limiting (Throttling)
Control the rate at which webhook events are delivered to your endpoint to prevent overwhelming your system.
From your endpoint details page, click the **Advanced** tab.
In the "Rate Limit (throttling)" section, click **Edit** to modify the rate limit settings.
By default, webhooks have no rate limit applied, meaning events are delivered as soon as they occur.
Configure your desired rate limit to control webhook delivery frequency and prevent system overload.
Use rate limiting when your webhook handler needs time to process events or when you want to batch multiple events together.
### Custom Headers
Add custom HTTP headers to all webhook requests sent to your endpoint. This is useful for authentication, routing, or adding metadata.
In the "Custom Headers" section, enter a **Key** and **Value** for each custom header.
Click the **+** button to add additional custom headers as needed.
Your custom headers are included in all webhook requests to this endpoint.
### Transformations
Transformations allow you to modify a webhook's payload and optionally redirect it to a different URL. This powerful feature enables you to:
* Modify the payload structure before processing
* Route webhooks to different endpoints based on content
* Add or remove fields from the payload
* Transform data formats
Toggle the **Enabled** switch to activate the transformation feature.
Click **Edit transformation** to define your transformation rules using JavaScript.
Use the transformation test interface to verify your transformation works correctly before going live.
Transformations can impact webhook delivery performance. Test thoroughly and keep transformation logic simple and efficient.
Transformations are particularly useful for:
* Converting between different data formats
* Filtering events based on specific criteria
* Adding computed fields to the payload
* Routing events to different microservices
## Monitoring Webhook Logs
The **Logs** tab provides comprehensive visibility into your webhook delivery status, allowing you to monitor, debug, and manage webhook events effectively.
Go to **Developer → Webhooks** and open the **Logs** tab.
View a table of all webhook delivery attempts with columns for Event type, Message ID, Event ID, Sent at, Attempted at, Response code, and Duration.
Use the search bar to find specific messages by ID or event type. Filter by status (Succeeded, Failed, Pending, etc.) to focus on the events you need to investigate.
Click on any message to open the message detail page, which shows:
* The complete webhook payload
* Every delivery attempt with response code and duration
* Timestamp of each attempt
* Any error messages from your endpoint
Each attempt carries a **Replay** action, so you can re-drive that one message without leaving the page.
## Activity Monitoring
Go to **Developer → Webhooks** and open the **Activity** tab for a view of delivery performance across your endpoints.
**Delivery activity** plots attempts over time, bucketed as **Attempts per 5 minutes**, **Attempts per hour**, or **Attempts per day** depending on the window. Each bar is split by outcome, and hovering a segment shows the status, the number of attempts, and its share of the total. On an endpoint, **Delivery stats (last 24h)** on the **Overview** tab summarizes the same information for the past day.
The **Error rate (24h)** column on the **Endpoints** tab tells you at a glance which endpoints need attention, before you open any of them.
## Replaying and Recovering Messages
How you re-drive a message depends on how many you need:
* **One message** — open it from the **Logs** tab and use the **Replay** action on the attempt. No need to open the endpoint.
* **A range of messages** — open the endpoint, since the bulk modes act on a single endpoint at a time.
### Replaying in Bulk
Open the endpoint from **Developer → Webhooks**. Three modes are available, each acting on that endpoint alone. The range you set depends on the mode:
| Mode | What it does | What you set |
| --------------------------- | --------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| **Recover failed messages** | Replays every message to this endpoint that failed. | A starting point: **8 hours ago**, **Yesterday**, **3 days ago**, **Last week**, or **2 weeks ago** |
| **Replay missing messages** | Replays messages that were never dispatched to this endpoint, for example after you subscribe it to a new event type. | The same starting points |
| **Bulk replay messages** | Replays messages matching the filters you choose, including ones that already delivered successfully. | **Since** and **Until** bounds, defaulting to the last two weeks, plus optional event types, channel, or tag |
On the endpoint, open **More actions** and pick one of the three modes above.
Fill in the range that mode asks for, as listed in the table.
Click **Recover** or **Replay**, depending on the mode you picked.
Every run appears under **Replay history** on the endpoint's **Overview** tab, with its mode, time range, status, and the number of messages resent.
## Email Alerts
Receive an email notification when webhook deliveries to an endpoint are failing, so you can address problems before they turn into a backlog.
Go to **Developer → Webhooks** and open the **Settings** tab.
Locate the **Email alerting** card.
Enter the addresses that should receive the alerts. Separate multiple addresses with commas, and leave the field empty to turn alerts off.
Click **Save** to apply your changes.
Enable email alerts to catch webhook delivery problems early and maintain reliable integrations.
## Deploy to Cloud Platforms
Ready to deploy your webhook handler to production? We provide platform-specific guides to help you deploy webhooks to popular cloud providers with best practices for each platform.
Deploy webhooks to Vercel with serverless functions
Run webhooks on Cloudflare's edge network
Integrate webhooks with Supabase
Deploy webhooks as Netlify serverless functions
Each platform guide includes environment setup, signature verification, and deployment steps specific to that provider.
## Related API Reference
API reference for creating and configuring webhook endpoints programmatically
API reference for retrieving and managing your webhook endpoints