IntegrationCustom destination
Custom Webhooks - Send Events to Any HTTP Endpoint
Webhooks are the universal escape hatch in the Meshes catalog. If the destination accepts HTTPS requests, Meshes can route product events there with the same retries, fan-out, and delivery visibility as first-party integrations.
user.signupinvoice.paidpage.completed|Actionssend_webhookThe event names shown here are examples. In Meshes, event types are fully customized for each organization.
What you can do
Supported actions with real product context behind them
Create the webhook connection in Meshes with an HTTPS endpoint URL. Meshes can validate the endpoint when the connection is created, then forward matching event payloads to that URL as rules fire.
Not every destination needs a dedicated first-party integration to be useful. Sometimes the system you need to reach is an internal service, a partner endpoint, or a SaaS tool that already exposes a clean webhook receiver.
Meshes gives those endpoints the same delivery layer as the rest of your stack. You configure the HTTPS URL in your Meshes workspace, create the rule once, and let Meshes forward matching event payloads without building a custom worker just for that destination.
send_webhookForward the event payload to an HTTPS endpoint
Use Meshes to deliver the matching product event to any receiver that can accept a webhook request, including internal services and unsupported third-party tools.
Common use cases
How Meshes teams usually put Webhooks to work
These are the workflows where this destination tends to matter first. The point is to keep the product event, the destination action, and the operational retry path in one place.
Reach internal services without writing a custom dispatcher
Send user.signup or billing events into your own downstream services while keeping retries and observability inside Meshes.
Support a destination before it has a dedicated integration page
If the tool exposes an HTTP endpoint, webhooks let you route events there now instead of waiting for first-party coverage.
Connect partner or customer-owned endpoints safely
Use customer workspaces and webhook connections so each tenant can receive the events relevant to its own external systems.
Keep unsupported tools in the same event layer
Custom webhooks let the long tail of your integration surface still benefit from Meshes fan-out, retries, and delivery history.
How it works
Connect the destination, define the rule, emit the event
In Meshes, the operating model is simple: create the connection in the workspace, create the rule, then let the event delivery layer handle the last mile.
Connect Webhooks
Create the webhook connection in Meshes with the HTTPS endpoint you want to reach and confirm the connection test succeeds.
Create routing rules in Meshes
Create rules for events like user.signup or invoice.paid, choose send_webhook, and decide which product events should be forwarded to that endpoint.
Emit the event and review delivery
Emit the event from your app or use Send Test Event in Meshes. Meshes forwards the payload, retries transient failures, and records the full delivery history for review or replay.
Event example
Emit the product event once
import MeshesEventsClient from '@mesheshq/events';
const meshes = new MeshesEventsClient(
process.env.WORKSPACE_PUBLISHABLE_KEY!,
);
await meshes.emit({
event: 'invoice.paid',
resource: 'invoice',
resource_id: 'inv_482',
payload: {
invoice_id: 'inv_482',
account_id: 'acct_913',
amount: 49900,
currency: 'usd',
paid_at: '2026-03-22T10:30:00.000Z',
},
});Connection model
Config only
Create the webhook connection in Meshes with an HTTPS endpoint URL. Meshes can validate the endpoint when the connection is created, then forward matching event payloads to that URL as rules fire.
Why Meshes
Why teams use Meshes for Webhooks
The benefit is not just that the destination is supported. It is that the destination sits inside the same fan-out, retry, replay, and delivery-visibility layer as the rest of your stack.
It covers the long tail of your integration surface
If the destination can receive HTTPS requests, you can usually route product events there without waiting for a bespoke connector.
You still get retries and replay
Custom endpoints deserve the same delivery guarantees as first-party integrations, especially when they power critical internal flows.
One event path can serve both first-party and custom destinations
Your app emits the event once and Meshes fans it out to supported integrations and webhook endpoints in parallel.
It is the fastest way to support unique customer workflows
When a customer needs their own endpoint in the loop, webhooks let you support that without hardcoding per-customer logic into the product.
Keep exploring
Related guides, use cases, docs, and comparison pages
These links are the next layer down: concrete patterns, supporting documentation, and the build-vs-buy context that usually comes up during evaluation.
Catalog
All integrations
Return to the integrations catalog and compare custom webhooks with the rest of the Meshes destination surface.
Open linkDocs
Quickstart
See the fastest path to creating a webhook connection and routing your first event through Meshes.
Open linkDocs
Integrations and rules reference
See the webhook action model and the rule metadata shape for send_webhook.
Open linkUse Case
User signup fan-out
See how one product event can reach several destinations at once from the same Meshes rule set.
Open linkGuide
Browse routing guides
See more Meshes patterns that can also be applied when the destination is a custom HTTPS endpoint.
Open linkCompare
Meshes vs. DIY
See what it takes to build your own webhook routing, retries, dead letters, and replay path from scratch.
Open link