Use CaseLifecycle fan-out

User Signup Fan-Out - One Event, Every Connected Tool Updated

A new-user signup should not stop at the app database. Each customer (or internal environment) wants the signal in their own CRM, their own lifecycle email tool, and their own team channel. Meshes turns one `user.signup` event into a clean fan-out across every workspace's connected destinations with per-workspace credentials, retries, and delivery history.

Event:user.signup· Destinations:HubSpotMailchimpIntercomSlack

The problem

Why this workflow breaks down without a delivery layer

Signup is the most universal fan-out event in SaaS, and it is also where teams start accreting one-off integration code. A single new user can trigger CRM updates, list membership changes, onboarding tags, and internal alerts — across whatever combination each workspace has connected.

Each destination wants a different shape and timing. HubSpot wants properties and lifecycle context, Mailchimp wants audience membership, Intercom wants support context, and Slack wants a short human-readable message. Multiplied by every tenant that connected a different mix, that signup handler becomes the riskiest part of your app.

The same problem applies to internal environments. Dev, staging, and production each want signup routed into their own tools without ever crossing the boundary. Workspaces let you treat tenants and environments with the same primitive.

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.signup

{
  "user_id": "usr_2048",
  "email": "alex@northstar.io",
  "first_name": "Alex",
  "last_name": "Nguyen",
  "plan": "starter",
  "source": "website",
  "utm_source": "google_ads",
  "signup_date": "2026-03-20T14:18:00Z"
}

HubSpot

Meshes updates contact properties and list membership using the workspace's own HubSpot connection.

Every workspace sees signup context land in its own CRM the moment the user lands — no per-tenant sync code in your app.

Mailchimp

Meshes adds the contact to the audience or list configured in the workspace.

Lifecycle email starts from the real signup event in each workspace, not a delayed nightly export.

Intercom

Meshes tags the user using the workspace's Intercom connection so onboarding and support flows inherit plan and source context.

Support and product in every workspace see the right segment from the first conversation.

Slack

Meshes posts a new-signup alert to whichever channel the workspace owner picked.

Each workspace — external tenant or internal env — gets signup visibility in the channel that actually watches it.

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.signup`enters Meshes once

import MeshesEventsClient from '@mesheshq/events';

const meshes = new MeshesEventsClient(
  process.env.WORKSPACE_PUBLISHABLE_KEY!,
);

await meshes.emit({
  event: 'user.signup',
  resource: 'membership_level',
  resource_id: 'starter',
  payload: {
    user_id: 'usr_2048',
    email: 'alex@northstar.io',
    first_name: 'Alex',
    last_name: 'Nguyen',
    plan: 'starter',
    source: 'website',
    utm_source: 'google_ads',
    signup_date: '2026-03-20T14:18:00Z',
  },
});

Across destinations

Each downstream tool gets the context it needs

• Rules decide which destinations receive signup context, and each workspace owns its own set.
• Meshes fans the event out in parallel so one slow destination does not serialize the signup path.
• Internal environment workspaces reuse the same rules against sandbox destinations, keeping test signups confined to their environment.

On every delivery

Retries, replay, and delivery history stay built in

• Field mappings let each destination receive the user payload it expects without hardcoding that projection in your app.
• Replay and delivery history make it obvious when one destination missed the event in a specific workspace and needs to be retried.
• Per-workspace OAuth and credentials mean one tenant's revoked token never affects another tenant's delivery.

Why this matters

Business impact, not just API plumbing

Every workspace aligned from signup

Signup is where lifecycle, marketing, support, and internal visibility begin. If those tools drift in a workspace, every downstream workflow in that tenant starts on bad footing.

Shorter time to first touch, everywhere

The faster each workspace's connected tools update, the faster the team that owns that workspace can respond to new signups, acquisition mix, and onboarding gaps.

A leaner signup handler

One product event should not require four API clients, four retry policies, and four failure paths inside the code path that creates a user — no matter how many tenants you serve.

Docs, integrations, and deeper architecture reading

Docs

Quickstart

Route your first lifecycle event end to end from the dashboard or code.

Open link

Docs

Send Events

See the publishable-key event ingestion pattern behind this signup flow.

Open link

Integration

HubSpot Integration

Update contact properties and list membership using each workspace's own credentials.

Open link

Integration

Intercom Integration

Apply tags so onboarding and support flows inherit the right context per tenant.

Open link

Blog

Fan-Out Architecture Guide

See why one signup event should reach multiple tools in parallel.

Open link

Blog

Event Routing for SaaS

Understand how routing rules decide which destinations should receive signup events.

Open link

Compare

Meshes vs. DIY

Compare one-event fan-out to hand-maintained signup workers and webhook branches per tenant.

Open link

Next stepStart free or view the documentation

Turn signup into one clean event instead of four API calls

Route `user.signup` through Meshes once and let every workspace — tenant or environment — keep its HubSpot, Mailchimp, Intercom, and Slack aligned.

Start free View documentation

Use CaseLifecycle fan-out

User Signup Fan-Out - One Event, Every Connected Tool Updated

A new-user signup should not stop at the app database. Each customer (or internal environment) wants the signal in their own CRM, their own lifecycle email tool, and their own team channel. Meshes turns one `user.signup` event into a clean fan-out across every workspace's connected destinations with per-workspace credentials, retries, and delivery history.

Start free View documentation

Event:user.signup· Destinations:HubSpotMailchimpIntercomSlack

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.signup

{
  "user_id": "usr_2048",
  "email": "alex@northstar.io",
  "first_name": "Alex",
  "last_name": "Nguyen",
  "plan": "starter",
  "source": "website",
  "utm_source": "google_ads",
  "signup_date": "2026-03-20T14:18:00Z"
}

HubSpot

Meshes updates contact properties and list membership using the workspace's own HubSpot connection.

Every workspace sees signup context land in its own CRM the moment the user lands — no per-tenant sync code in your app.

Mailchimp

Meshes adds the contact to the audience or list configured in the workspace.

Lifecycle email starts from the real signup event in each workspace, not a delayed nightly export.

Intercom

Meshes tags the user using the workspace's Intercom connection so onboarding and support flows inherit plan and source context.

Support and product in every workspace see the right segment from the first conversation.

Slack

Meshes posts a new-signup alert to whichever channel the workspace owner picked.

Each workspace — external tenant or internal env — gets signup visibility in the channel that actually watches it.

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.signup`enters Meshes once

import MeshesEventsClient from '@mesheshq/events';

const meshes = new MeshesEventsClient(
  process.env.WORKSPACE_PUBLISHABLE_KEY!,
);

await meshes.emit({
  event: 'user.signup',
  resource: 'membership_level',
  resource_id: 'starter',
  payload: {
    user_id: 'usr_2048',
    email: 'alex@northstar.io',
    first_name: 'Alex',
    last_name: 'Nguyen',
    plan: 'starter',
    source: 'website',
    utm_source: 'google_ads',
    signup_date: '2026-03-20T14:18:00Z',
  },
});

Across destinations

Each downstream tool gets the context it needs

• Rules decide which destinations receive signup context, and each workspace owns its own set.
• Meshes fans the event out in parallel so one slow destination does not serialize the signup path.
• Internal environment workspaces reuse the same rules against sandbox destinations, keeping test signups confined to their environment.

On every delivery

Retries, replay, and delivery history stay built in

• Field mappings let each destination receive the user payload it expects without hardcoding that projection in your app.
• Replay and delivery history make it obvious when one destination missed the event in a specific workspace and needs to be retried.
• Per-workspace OAuth and credentials mean one tenant's revoked token never affects another tenant's delivery.

Why this matters

Business impact, not just API plumbing

Every workspace aligned from signup

Signup is where lifecycle, marketing, support, and internal visibility begin. If those tools drift in a workspace, every downstream workflow in that tenant starts on bad footing.

Shorter time to first touch, everywhere

The faster each workspace's connected tools update, the faster the team that owns that workspace can respond to new signups, acquisition mix, and onboarding gaps.

A leaner signup handler

One product event should not require four API clients, four retry policies, and four failure paths inside the code path that creates a user — no matter how many tenants you serve.