Core Concepts

If you keep six concepts straight, Meshes becomes easy to reason about:

1. workspaces
2. connections
3. events
4. rules
5. delivery
6. usage and limits

1. Workspaces

A workspace is the isolation boundary in Meshes.

Most teams map a workspace to one of these:

• a customer or tenant
• an environment like dev, staging, or prod
• a business unit or product line

Each workspace owns its own:

• connections and credentials
• rules and routing configuration
• event history
• delivery status and failures
• usage consumption within your account limits

This is what gives Meshes clean multi-tenant separation.

2. Connections

A connection is a configured destination inside a workspace.

Examples:

• a HubSpot account connected with OAuth
• a Mailchimp account connected with an API key
• a generic webhook endpoint
• a Slack, Salesforce, or Intercom destination

Connections are always workspace-scoped. If three customers each connect their own HubSpot account, that is three separate HubSpot connections in three separate workspaces.

Common connection types

OAuth connections

• Meshes handles the authorization flow
• Meshes stores and refreshes tokens securely

API key or token connections

• you paste credentials once
• Meshes stores them securely and uses them for delivery

Webhook connections

• you configure an HTTP endpoint
• Meshes handles request delivery, retries, and status tracking

3. Events

An event is the unit of work your app sends into Meshes.

Typical event names:

• contact.created
• trial.started
• invoice.paid
• subscription.canceled

Good event names are:

• dot-separated
• stable over time
• based on product actions, not downstream tools

Event payloads

A typical event looks like this:

{
  "event": "contact.created",
  "payload": {
    "id": "contact_123",
    "email": "jane@example.com",
    "first_name": "Jane",
    "last_name": "Doe",
    "source": "marketing-site",
    "tier": "pro"
  }
}

Optional fields like resource and resource_id can help you segment or identify the object tied to the event.

How workspace is determined

• with a publishable key, the workspace is inferred from the key
• with a machine JWT, the request is scoped by the authenticated principal

That means most event payloads do not need to carry a workspace identifier explicitly.

4. Rules

A rule tells Meshes what to do when a matching event arrives.

At a high level, a rule combines:

• an event type
• optional conditions
• an action for a specific connection

Examples:

• when contact.created, send to HubSpot
• when trial.started, send to Mailchimp
• when invoice.paid, post to an internal webhook

You can define multiple rules for the same event. That is how fan-out works.

Why rules matter

Rules let you keep routing logic out of your app.

Your app emits the business event once. Meshes decides which destinations should receive it.

Fast validation path

You do not need to wire code first to prove a rule works.

You can open a rule in the UI and click Send Test Event to validate the entire path before sending real application traffic.

5. Delivery

Once an event enters Meshes, the platform takes over delivery behavior.

That includes:

• evaluating matching rules
• fan-out to multiple destinations
• retries with backoff for transient failures
• delivery status per destination
• failure inspection and replay

Event history

The Events UI is where you inspect what happened:

• which rules matched
• which destinations succeeded
• which destinations failed
• whether retries happened
• whether replay is needed

Reliability expectations

Meshes is asynchronous. Deliveries may be retried and may not be globally ordered across every destination.

Downstream systems should still be designed to tolerate:

• repeated deliveries
• out-of-order arrivals
• partial destination failures

6. Usage and Limits

Meshes tracks usage at the account and workspace level.

The most important unit is usually events, but plans also include boundaries around:

• workspaces
• connections
• rules
• retention
• team access

Treat these as design constraints when you model your integration surface.

For example:

• do not emit unnecessary duplicate events
• keep workspace boundaries intentional
• avoid creating rules that overlap accidentally

Putting It Together

The normal Meshes flow is:

1. create a workspace
2. connect one or more destinations
3. define rules for the events you care about
4. send events into Meshes
5. inspect delivery and replay failures if needed

That is the core model behind everything else in the product.