• Use Cases
  • Pricing
  • Security
  • Docs
Sign InStart free

The outbound integration layer for SaaS products: emit once, then let Meshes handle routing, retries, fan-out, and delivery history.

© Copyright 2026 Meshes, Inc. All Rights Reserved.

About
  • About
  • Security
  • Blog
  • Contact
  • FAQ
Product
  • Pricing
  • Demo
  • Integrations
  • Guides
  • Changelog
  • Status
Compare
  • All comparisons
  • Build vs buy
  • vs Paragon
  • vs Merge
  • vs n8n
  • vs Zapier
  • vs Make
Use Cases
  • All use cases
  • Embedded CRM sync
  • Per-tenant Slack
  • HMAC webhooks
  • Multi-env workspaces
  • Payment failed
  • User signup fan-out
  • Churn prevention
  • Trial expired events
Developers
  • Documentation
  • Agents
  • Tools
  • API Reference
  • MCP Server
  • llms.txt
Legal
  • Terms of Service
  • Privacy Policy
  • Acceptable Use Policy
  • Cookie Policy

Use CaseConversion timing

Trial Expiry Notifications - Keep Conversion Workflows On Time

Trial-ending events only work when timing is tight. Each workspace — a customer running their own conversion motion, or your own env workspace running internal workflows — wants the signal in email, in-app messaging, CRM, lifecycle tools, or an internal alert path when trial time or usage allowance is running low. Meshes routes trial.ending once and delivers it per workspace with retries and replay built in.

Start freeView documentation

Event:trial.ending· Destinations:ResendIntercomSalesforceHubSpot

The problem

Why this workflow breaks down without a delivery layer

A trial-ending workflow breaks down fast when every destination waits on a different job or export. Email goes out late, internal notifications miss the account approaching expiry or usage depletion, Intercom does not know the user is near the end of the trial, and Salesforce never gets the engagement context the rep needs — multiplied by every workspace that has its own mix.

The technical problem is not generating the event. It is delivering that signal to each workspace on time with the fields each destination expects. When those paths drift, your customers see their conversion workflows become inconsistent exactly when timing matters most.

Teams often discover this after a workspace's campaign underperforms or a rep says they never saw the account in time. Reliable per-workspace delivery is what makes a trial-ending workflow usable before trial time or usage allowance runs out.

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

trial.ending
{
  "user_id": "usr_8803",
  "email": "maria@lighthouse.io",
  "trial_end_date": "2026-03-24",
  "plan_viewed": "growth",
  "usage_percent": 92,
  "features_used": ["exports", "alerts", "crm_sync"],
  "days_active": 11
}
Resend

Meshes triggers the conversion email template the workspace has connected, with trial context, usage context, and next steps.

Each workspace's email path fires from the actual trial-ending event instead of a delayed batch job or usage export.

Intercom

Meshes tags the user through the workspace's Intercom connection for targeted in-app messaging.

Product and support in each workspace align in-app nudges with the same trial and usage context the email system sees.

Salesforce

Meshes updates engagement-related fields using the workspace's Salesforce credentials and mapping.

Reps inside each workspace see who is active, what plan they viewed, how close usage is to the limit, and when the trial ends without a manual export.

HubSpot

Meshes updates lifecycle or list state in the workspace's HubSpot connection for conversion-oriented workflows.

Marketing in each workspace keeps audience state in sync with the real trial-ending signal.

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

trial.endingenters Meshes once

import MeshesEventsClient from '@mesheshq/events';

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

await meshes.emit({
  event: 'trial.ending',
  resource: 'membership_level',
  resource_id: 'growth',
  payload: {
    user_id: 'usr_8803',
    email: 'maria@lighthouse.io',
    trial_end_date: '2026-03-24',
    plan_viewed: 'growth',
    usage_percent: 92,
    features_used: ['exports', 'alerts', 'crm_sync'],
    days_active: 11,
  },
});

Across destinations

Each downstream tool gets the context it needs

  • • Each workspace owns its rules; your app emits one trial.ending event and Meshes resolves the destinations per tenant.
  • • If your product already knows usage is almost depleted, include that context in the trial-ending payload so downstream notifications can reflect the same product state.
  • • Each destination has isolated retry behavior, which keeps one flaky API in one workspace from delaying the rest of that workflow.
  • • Replay gives every workspace a clean way to resend a missed trial-ending delivery after the underlying issue is fixed.

On every delivery

Retries, replay, and delivery history stay built in

  • • Delivery timing matters, so Meshes keeps the fan-out path observable per workspace instead of hiding failures inside separate cron jobs or ad hoc workers.
  • • Per-workspace OAuth keeps each tenant's provider credentials isolated, so a refresh or revoke stays scoped.
  • • Internal environment workspaces can validate trial-ending flows against sandbox tools before pointing them at real customer data.

Why this matters

Business impact, not just API plumbing

Conversion and depletion windows that land on time

A trial-ending workflow only works if the signal arrives when the customer can still act on it. Delayed expiry or usage-depletion notifications erase the advantage inside any workspace.

Product, sales, and email aligned inside each tenant

Resend, Intercom, Salesforce, and HubSpot should all react from the same trial context so messaging and outreach do not contradict each other inside a workspace.

Internal alerts from the same product state

Internal environment workspaces can use the same trial.ending payload to notify the team before a trial expires or usage runs low, without creating a separate timer job for every path.

Related

Docs, integrations, and deeper architecture reading

Guide

Tag Intercom Users on Trial Expiry

Configure an Intercom handoff from trial.ending so in-app messaging reacts to product state instead of a generic timer.

Open link

Docs

Quickstart

See the full event-routing flow behind a time-sensitive conversion use case.

Open link

Docs

Send Events

See the event-ingestion pattern behind this trial-ending workflow.

Open link

Integration

Resend Integration

Send trial-expiry email notifications from the same event that updates the rest of the workspace.

Open link

Integration

Intercom Integration

Tag trial-ending users so in-app messaging and support context stay current in every workspace.

Open link

Blog

What Is Fan-out Architecture?

Why one trial.ending event can safely reach email, CRM, in-app messaging, and internal alert paths.

Open link

Blog

Build a Reliable Integration Layer

Why time-sensitive conversion workflows break when you hand-roll the delivery infrastructure per tenant.

Open link

Compare

Meshes vs. DIY

Compare event-driven trial routing with maintaining cron jobs and webhook glue yourself.

Open link

Next stepStart free or view the documentation

Keep trial-ending workflows on time across every workspace

Route trial.ending through Meshes once and keep each workspace's email, CRM, support, internal alerts, and lifecycle tools aligned around the conversion window.

Start freeView documentation