• Use Cases
  • Pricing
  • Security
  • Docs
Sign InStart free

The outbound integration layer for SaaS products: emit once, then let Meshes handle routing, retries, fan-out, and delivery history.

© Copyright 2026 Meshes, Inc. All Rights Reserved.

About
  • About
  • Security
  • Blog
  • Contact
  • FAQ
Product
  • Pricing
  • Demo
  • Integrations
  • Guides
  • Changelog
  • Status
Compare
  • All comparisons
  • Build vs buy
  • vs Paragon
  • vs Merge
  • vs n8n
  • vs Zapier
  • vs Make
Use Cases
  • All use cases
  • Embedded CRM sync
  • Per-tenant Slack
  • HMAC webhooks
  • Multi-env workspaces
  • Payment failed
  • User signup fan-out
  • Churn prevention
  • Trial expired events
Developers
  • Documentation
  • Agents
  • Tools
  • API Reference
  • MCP Server
  • llms.txt
Legal
  • Terms of Service
  • Privacy Policy
  • Acceptable Use Policy
  • Cookie Policy

Use CasePer-tenant webhook signing

Per-Tenant Webhooks With HMAC Signing - Customer-Provided Secrets From the Embed

Every webhook integration eventually hits the same question: how does my customer know this request is really from you? Meshes lets each customer register their own webhook URL and HMAC secret directly in the embedded workspace UI, then signs every delivery per workspace with that secret — so your product ships a trustworthy customer-facing webhook integration without shipping one line of signing code in your app.

Start freeView documentation

Event:order.completed· Destinations:Webhook (HMAC-signed)Webhook (secondary)Slack

The problem

Why this workflow breaks down without a delivery layer

Webhooks are the lowest-friction way to let customers with their own backends receive your product events. They are also the highest-trust surface you expose: the customer's receiver needs to be certain each request is really from you and not from a replay, a spoof, or an unrelated misrouted retry.

Rolling your own per-customer HMAC layer means your SaaS owns secret storage, rotation, signature algorithm support, timestamp tolerance, and retry semantics for every tenant. That is a lot of cryptographic surface for a feature most teams want to ship as a toggle.

The embedded iPaaS pattern moves that work into Meshes. Each customer enters their webhook URL and HMAC secret inside your embedded workspace UI. Your app emits product events; Meshes signs every delivery with the customer's own secret, retries on failure, and gives the customer a delivery log they can audit. The same pattern covers your internal environments: separate webhook endpoints per dev, staging, and production workspace with their own secrets.

The event flow

One event in. Every downstream system stays in sync.

Meshes receives the source event once, maps it to the right destinations per workspace, and keeps delivery visible when downstream APIs fail.

Event payload

order.completed
{
  "order_id": "ord_lannister_77",
  "customer_id": "cus_lannister",
  "account_id": "acc_casterly",
  "total_cents": 12900,
  "currency": "usd",
  "items": 3,
  "completed_at": "2026-04-17T18:22:00Z"
}
Webhook (HMAC-signed)

Meshes POSTs the event to the URL the customer registered in the embed, signing the payload with the HMAC secret they provided. Every request carries a signature header and a timestamp the customer can verify.

Customer receivers can trust every request is really from you — with no shared secret in your application code and no crypto library your team has to maintain.

Webhook (secondary)

Customers who want a second endpoint — for example, an audit log or a staging replica — can register an additional URL and secret inside the same workspace.

Multiple receivers stay consistent without your app branching; each endpoint is signed with its own secret and retried independently.

Slack

Optional operational alert that fires when a webhook delivery has exhausted retries, routed to the customer's own Slack workspace.

The customer's ops team sees delivery failures in real time without waiting for you to notice.

How Meshes handles it

What Meshes takes off your team's plate

Instead of maintaining separate workers, retry logic, and visibility per destination, Meshes gives you one event path, destination-aware routing, and built-in delivery guarantees.

From your product

order.completedenters Meshes once

import MeshesEventsClient from '@mesheshq/events';

const meshes = new MeshesEventsClient(
  tenant.meshesPublishableKey,
);

await meshes.emit({
  event: 'order.completed',
  resource: 'order',
  resource_id: 'ord_lannister_77',
  payload: {
    order_id: 'ord_lannister_77',
    customer_id: 'cus_lannister',
    account_id: 'acc_casterly',
    total_cents: 12900,
    currency: 'usd',
    items: 3,
    completed_at: '2026-04-17T18:22:00Z',
  },
});

Across destinations

Each downstream tool gets the context it needs

  • • Webhook URL, HMAC secret, and signature algorithm are stored per workspace — configured by the customer, never in your app.
  • • Rotating a secret is a single action inside the embed; the next delivery uses the new secret automatically with no deploy on your side.
  • • Rules can still filter which events reach the webhook (severity, resource type, customer tier) at the workspace level.

On every delivery

Retries, replay, and delivery history stay built in

  • • Every delivery carries a signature header plus a timestamp so the customer can reject replays outside their tolerance window.
  • • Retries are signed fresh on each attempt — the customer's receiver never sees a stale signature after a backoff pause.
  • • Dead-lettered webhooks remain in the workspace for replay, with the signing key still scoped to the tenant so replays stay verifiable.

Why this matters

Business impact, not just API plumbing

Trustworthy webhooks without owning crypto

Your customers verify every request with their own secret. Your app never stores one, rotates one, or ships signing code — the embed and Meshes own that surface.

Customer-controlled rotation

When a customer rotates their HMAC secret, they do it in the embed. Your product does not redeploy, re-sign, or coordinate a cutover.

Audit-ready delivery history per tenant

Every workspace has its own signed delivery log, retry trail, and replay controls. Customers can prove what was delivered and what was not without asking your team.

Related

Docs, integrations, and deeper architecture reading

Docs

Webhooks Integration

See how per-workspace webhook destinations, signatures, and retries are configured inside Meshes.

Open link

Docs

Embedded Workspaces

See how customers register their webhook URL and HMAC secret from inside your product via the embed.

Open link

Docs

Embed Security

Understand how workspace-scoped sessions keep customer secrets from ever reaching your backend.

Open link

Blog

Webhook Retry Logic Done Right

Why exponential backoff and jitter matter for signed webhook delivery.

Open link

Blog

Dead Letter Queues for Webhooks

How to keep failed signed deliveries available for replay without losing trust.

Open link

Compare

Meshes vs. DIY

See what it costs to own per-tenant HMAC signing, secret rotation, and replay yourself.

Open link

Next stepStart free or view the documentation

Ship customer-verifiable webhooks without crypto in your app

Let customers register their webhook URL and HMAC secret from the embed, and emit one event from your product — Meshes signs every delivery with the tenant's own secret.

Start freeView documentation