Use CasePer-customer CRM delivery

Embedded Customer CRM Sync - Route Product Events Into Each Customer's CRM

Your customers want your product events inside their CRM, not yours. Meshes lets each customer connect their own HubSpot or Salesforce from the embedded workspace UI, then routes one product event into every customer's CRM with per-workspace credentials, retries, and per-destination delivery history — so your team ships CRM sync as a feature without managing one OAuth token per tenant.

Event:user.activated· Destinations:HubSpotSalesforceWebhook

The problem

Why this workflow breaks down without a delivery layer

The first time a customer asks for CRM sync, you build it for one tenant. By the tenth customer, you're storing per-customer OAuth tokens, maintaining per-customer field mappings, running per-customer retry logic, and answering support tickets about why a contact didn't show up in their HubSpot. The feature stops scaling long before the customer count does.

The embedded iPaaS pattern flips the work. Each customer connects their own CRM from inside your product through a Meshes workspace they control. They pick the fields that matter to them, they rotate their own credentials, and they see their own delivery history. Your app only emits product events.

The same pattern covers your internal stack. Run a workspace per environment so dev, staging, and production each have their own CRM connection — usually pointing at sandbox accounts — and test events never reach the real CRM.

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

user.activated

{
  "user_id": "usr_skywalker",
  "email": "luke@rebellion.dev",
  "account_id": "acc_rebellion",
  "activated_at": "2026-04-17T15:06:00Z",
  "plan": "growth",
  "source": "onboarding_checklist"
}

HubSpot

Meshes delivers the event into each workspace's HubSpot connection using the OAuth token the customer authorized from the embed.

Every customer sees your product activations update their own HubSpot with the fields they mapped — no per-tenant code in your app.

Salesforce

Meshes routes the same event into workspaces whose customers connected Salesforce instead, using that tenant's OAuth and field mapping.

Customers on Salesforce get the same product events inside their CRM without your team owning two integration paths in code.

Webhook

For customers whose CRM isn't in the supported catalog, Meshes delivers the event to the URL they register in the embed.

Long-tail CRM support falls out of the same event — your product treats every tenant the same regardless of the destination they picked.

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

`user.activated`enters Meshes once

import MeshesEventsClient from '@mesheshq/events';

// Each tenant's workspace has its own publishable key.
// Your backend looks it up per customer and emits once.
const meshes = new MeshesEventsClient(
  tenant.meshesPublishableKey,
);

await meshes.emit({
  event: 'user.activated',
  resource: 'membership_level',
  resource_id: 'growth',
  payload: {
    user_id: 'usr_skywalker',
    email: 'luke@rebellion.dev',
    account_id: 'acc_rebellion',
    activated_at: '2026-04-17T15:06:00Z',
    plan: 'growth',
    source: 'onboarding_checklist',
  },
});

Across destinations

Each downstream tool gets the context it needs

• Rules live in each tenant's workspace; customers configure which events route to their CRM and which fields get mapped.
• Your app emits one event per affected user; Meshes resolves the destination set from the workspace, not from your code.
• Workspaces your team owns (dev, staging, production) use the same rules shape but point at sandbox or production CRM accounts.

On every delivery

Retries, replay, and delivery history stay built in

• Credentials are scoped per workspace; an OAuth refresh or revoke on one tenant never affects any other tenant.
• Retries and dead letters run independently per workspace, so a slow provider on one customer's account never stalls another customer's delivery.
• Each customer can replay a failed delivery from their own embedded history view without filing a ticket or touching your app code.

Why this matters

Business impact, not just API plumbing

CRM sync as a product feature, not a per-tenant project

Customers connect their own CRM from inside your product. Your app emits one event; per-tenant delivery is a workspace concern, not an engineering backlog item.

Credentials and mappings scoped to the customer

Every workspace owns its OAuth token, field mappings, and delivery history. Your main codebase never stores or rotates per-customer CRM secrets.

One primitive for tenants and environments

The same workspace model that isolates your customers also isolates dev, staging, and production inside your own SaaS — so test events never reach a real CRM.

Docs, integrations, and deeper architecture reading

Docs

Embedded Workspaces

See how customers connect their own CRM from inside your product via an embedded Meshes workspace.

Open link

Docs

Session API

Mint per-workspace sessions so each customer only ever sees and configures their own connections.

Open link

Integration

HubSpot Integration

Per-workspace HubSpot connections driven by each customer's OAuth token and field mapping.

Open link

Integration

Salesforce Integration

Deliver the same product events into Salesforce workspaces without a second code path.

Open link

Blog

Design Multi-Tenant Integrations

Why per-tenant credentials, mappings, and delivery history belong in the workspace, not your codebase.

Open link

Compare

Meshes vs. Paragon

Compare an event-shaped embedded iPaaS against a broader all-in-one platform for customer-facing integrations.

Open link

Next stepStart free or view the documentation

Let every customer connect their own CRM

Emit one product event and let Meshes route it into each customer's HubSpot, Salesforce, or webhook using the credentials and mappings they configured from your embedded workspace UI.

Start free View documentation

Use CasePer-customer CRM delivery

Embedded Customer CRM Sync - Route Product Events Into Each Customer's CRM

Your customers want your product events inside their CRM, not yours. Meshes lets each customer connect their own HubSpot or Salesforce from the embedded workspace UI, then routes one product event into every customer's CRM with per-workspace credentials, retries, and per-destination delivery history — so your team ships CRM sync as a feature without managing one OAuth token per tenant.

Start free View documentation

Event:user.activated· Destinations:HubSpotSalesforceWebhook

The problem

Why this workflow breaks down without a delivery layer

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

user.activated

{
  "user_id": "usr_skywalker",
  "email": "luke@rebellion.dev",
  "account_id": "acc_rebellion",
  "activated_at": "2026-04-17T15:06:00Z",
  "plan": "growth",
  "source": "onboarding_checklist"
}

HubSpot

Meshes delivers the event into each workspace's HubSpot connection using the OAuth token the customer authorized from the embed.

Every customer sees your product activations update their own HubSpot with the fields they mapped — no per-tenant code in your app.

Salesforce

Meshes routes the same event into workspaces whose customers connected Salesforce instead, using that tenant's OAuth and field mapping.

Customers on Salesforce get the same product events inside their CRM without your team owning two integration paths in code.

Webhook

For customers whose CRM isn't in the supported catalog, Meshes delivers the event to the URL they register in the embed.

Long-tail CRM support falls out of the same event — your product treats every tenant the same regardless of the destination they picked.

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

`user.activated`enters Meshes once

import MeshesEventsClient from '@mesheshq/events';

// Each tenant's workspace has its own publishable key.
// Your backend looks it up per customer and emits once.
const meshes = new MeshesEventsClient(
  tenant.meshesPublishableKey,
);

await meshes.emit({
  event: 'user.activated',
  resource: 'membership_level',
  resource_id: 'growth',
  payload: {
    user_id: 'usr_skywalker',
    email: 'luke@rebellion.dev',
    account_id: 'acc_rebellion',
    activated_at: '2026-04-17T15:06:00Z',
    plan: 'growth',
    source: 'onboarding_checklist',
  },
});

Across destinations

Each downstream tool gets the context it needs

• Rules live in each tenant's workspace; customers configure which events route to their CRM and which fields get mapped.
• Your app emits one event per affected user; Meshes resolves the destination set from the workspace, not from your code.
• Workspaces your team owns (dev, staging, production) use the same rules shape but point at sandbox or production CRM accounts.

On every delivery

Retries, replay, and delivery history stay built in

• Credentials are scoped per workspace; an OAuth refresh or revoke on one tenant never affects any other tenant.
• Retries and dead letters run independently per workspace, so a slow provider on one customer's account never stalls another customer's delivery.
• Each customer can replay a failed delivery from their own embedded history view without filing a ticket or touching your app code.

Why this matters

Business impact, not just API plumbing

CRM sync as a product feature, not a per-tenant project

Customers connect their own CRM from inside your product. Your app emits one event; per-tenant delivery is a workspace concern, not an engineering backlog item.

Credentials and mappings scoped to the customer

Every workspace owns its OAuth token, field mappings, and delivery history. Your main codebase never stores or rotates per-customer CRM secrets.

One primitive for tenants and environments

The same workspace model that isolates your customers also isolates dev, staging, and production inside your own SaaS — so test events never reach a real CRM.