Event Routing for SaaS: How to Send the Right Data to the Right Destination

This works for one or two integrations. It falls apart when you add a third destination, a second event type, or a customer who wants both HubSpot and Salesforce.

Stage 2: Queue + workers

You push events onto a queue and let workers handle routing. Better for latency, but the routing logic just moved from your controller to your worker:

Now you maintain destination-specific code in a worker, plus the queue infrastructure, plus retry logic per destination. Every new integration is a new case branch, a new set of credentials to manage, and a new surface area for bugs.

Stage 3: Configuration-driven routing

This is where you want to end up. Instead of code that maps events to destinations, you have a routing layer that evaluates rules against incoming events and dispatches them to configured connections.

Events flow in. Rules decide where they go. Connections handle delivery. Your application code doesn't change when you add a new destination—you add a rule.

What a routing layer needs to do well

A routing layer that works at scale needs more than a switch statement:

Fan-out. One event triggers multiple destinations in parallel. If lead.created needs to reach HubSpot, a webhook, and a Slack channel, all three deliveries happen concurrently—not sequentially.

Payload transformation. Each destination expects different shapes. The routing layer should map your canonical event payload into destination-specific formats without polluting your app with per-destination serialization logic.

Conditional routing. Not every event goes to every destination. Rules should support conditions: route only if payload.plan === 'enterprise', or only if the event type matches a pattern, or only for specific workspaces.

Tenant isolation. In a multi-tenant SaaS, Customer A's HubSpot credentials and routing rules should be completely separate from Customer B's. A routing failure for one tenant should never affect another.

Delivery guarantees. Routing without reliable delivery is just a fancier way to lose events. The routing layer needs retries, backoff, dead letters, and per-destination observability baked in.

How Meshes handles event routing

Meshes is built around this exact model: your app emits events, and the platform handles routing, transformation, and delivery.

The pieces:

• Event types define what your app can emit (e.g., lead.created, invoice.paid).
• Connections represent destinations—HubSpot, Salesforce, a webhook URL, a Slack channel.
• Rules bind event types to connections with optional conditions and payload mappings.
• Workspaces isolate everything per tenant: credentials, rules, delivery logs.

Your app sends one event:

The routing layer takes over: it evaluates which rules match lead.created for that workspace, transforms the payload per destination, and delivers to each connection in parallel—with retries, backoff, and dead letters handled automatically.

When to invest in routing infrastructure

If your integration story is one event type going to one destination, you don't need routing infrastructure. A direct API call is fine.

But watch for these inflection points:

• Multiple destinations per event. The moment one event needs to reach two or more places, you have a fan-out problem.
• Customer-configurable integrations. If customers choose which CRM or webhook to connect, routing logic can't be hardcoded.
• Growing event catalog. Five event types going to three destinations is fifteen routing paths. Ten event types and five destinations is fifty. The combinatorics get ugly fast.
• Multi-tenant isolation. If each customer has their own credentials and rules, routing logic needs to be scoped per tenant—not shared in a monolithic worker.

At that point, externalizing routing to a dedicated layer saves more engineering time than it costs.

The bottom line

Event routing is the connective tissue between your product and the outside world. Done well, it's invisible—events flow to the right places, in the right shape, without your team touching integration code every sprint.

Done poorly, it's a tangled web of per-destination code, customer-specific branches, and retry logic scattered across your codebase.

A dedicated integration layer like Meshes lets you define routing as configuration—not code. Emit events, define rules, plug in destinations. The platform handles the rest.

Want routing that scales with your customer base? Join Meshes and stop hardcoding integrations.