Event:alert.triggered· Destinations:SlackWebhookResend
The problem
A customer asks for Slack. You add OAuth, build a channel picker, store the token, and ship it. Then the next customer asks to send different event types to different channels, and suddenly you're building per-tenant routing in your own code. By the time you have a dozen customers, Slack has stopped being an integration and started being a subsystem.
The embedded iPaaS pattern keeps this scoped. Each customer connects their own Slack workspace from the Meshes embed, picks their channels, and configures rules — which event types fire to which channel, and whether to alert only above a threshold. Your app emits the product event once; Meshes fans it out to every workspace's Slack connection.
The same model works for your own SaaS. Run separate workspaces for dev, staging, and production so noisy test alerts never wake up on-call in #prod-alerts, and every environment has its own Slack connection it can safely drown.
The event flow
Meshes receives the source event once, maps it to the right destinations per workspace, and keeps delivery visible when downstream APIs fail.
Event payload
alert.triggered{
"alert_id": "alrt_tyrion_42",
"account_id": "acc_casterly",
"severity": "high",
"resource": "api_latency_p95",
"value": 1840,
"threshold": 1000,
"triggered_at": "2026-04-17T16:02:00Z"
}Meshes posts a formatted alert to the channel each customer picked when they connected Slack from your embedded workspace UI.
Every tenant sees product alerts arrive in their own Slack workspace — no per-customer OAuth code, channel lookup, or token refresh in your app.
Customers not on Slack can point the same event at a webhook endpoint they register inside the embed.
Long-tail alerting paths (Teams bridges, internal dashboards, on-call systems) fall out of the same product event.
For customers who prefer email, Meshes can route alert-triggered events to a transactional email template with the alert context pre-filled.
Customer admins get a mailbox trail of triggered alerts without your app owning another delivery path.
How Meshes handles it
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
alert.triggeredenters Meshes onceimport MeshesEventsClient from '@mesheshq/events';
const meshes = new MeshesEventsClient(
tenant.meshesPublishableKey,
);
await meshes.emit({
event: 'alert.triggered',
resource: 'alert',
resource_id: 'alrt_tyrion_42',
payload: {
alert_id: 'alrt_tyrion_42',
account_id: 'acc_casterly',
severity: 'high',
resource: 'api_latency_p95',
value: 1840,
threshold: 1000,
triggered_at: '2026-04-17T16:02:00Z',
},
});Across destinations
On every delivery
Why this matters
Customers connect their own Slack from inside your product. Your app emits one event per alert; per-tenant channel routing lives in the workspace.
The customer picks the severity, the channel, and the filter. Your support team stops fielding "can you quiet the alert for our staging?" requests.
Run dev, staging, and production workspaces internally so load tests never page #alerts and every environment has its own noisy channel.
Related
Docs
See how customers connect Slack from inside your product via an embedded Meshes workspace.
Open linkDocs
Understand the OAuth flow customers use to connect Slack without secrets ever touching your backend.
Open linkIntegration
Per-workspace Slack connections with each tenant's own OAuth token and channel selection.
Open linkUse Case
See the same per-workspace pattern applied to HubSpot and Salesforce connections.
Open linkBlog
Why threshold-based routing belongs with the event layer, not the alerting subsystem.
Open linkCompare
Compare a focused embedded-delivery layer against an all-in-one platform for customer-facing Slack.
Open link