Event: user.signup · Destinations: HubSpot, Mailchimp, Intercom, Slack
The problem
Signup is the most universal fan-out event in SaaS, but 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 four different systems.
Each destination wants 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. Teams usually stitch this together in the signup handler until it becomes the riskiest part of the flow.
The problem compounds as you add destinations or let customers configure their own integrations. One product event should update the whole stack without turning signup into a maze of destination-specific branches.
The event flow
Each use case follows the same product story: Meshes receives the source event once, maps it to the right destinations, and keeps delivery visible when downstream APIs fail.
Event 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"
}HubSpot
Meshes updates contact properties and list membership for lifecycle and campaign tracking.
Sales and growth have the right source, plan, and signup metadata the moment the user lands.
Mailchimp
Meshes adds the contact to the right audience or list for welcome automation.
Lifecycle email starts from the actual signup event instead of a delayed export or nightly sync.
Intercom
Meshes tags the user so onboarding and support workflows know plan and source context.
Support and product teams see the right customer segment from the first conversation.
Slack
Meshes sends a new-signup alert directly to the team channel.
The team gets immediate visibility into new accounts, campaigns, and higher-value signups.
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
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
On every delivery
Why this matters
Signup is where lifecycle, marketing, support, and internal visibility begin. If those tools drift, every downstream workflow starts on bad footing.
The faster HubSpot, Mailchimp, Intercom, and Slack update, the faster your team can respond to source quality, new signups, and onboarding gaps.
One product event should not require four API clients, four retry policies, and four failure paths inside the code path that creates a user.
Related
Docs
Route your first lifecycle event end to end from the dashboard or code.
Open linkDocs
See the publishable-key event ingestion pattern behind this signup flow.
Open linkIntegration
Update contact properties and list membership from event-driven rules.
Open linkIntegration
Apply tags so onboarding and support workflows inherit the right context.
Open linkBlog
See why one signup event should reach multiple tools in parallel.
Open linkBlog
Understand how routing rules decide which destinations should receive signup events.
Open linkCompare
Compare one-event fan-out to hand-maintained signup workers and webhook branches.
Open link