Core Concepts

• Workspaces
• Connections
• Event Types & Resources
• Rules
• Events & Delivery
• Usage & Limits

Workspaces

A workspace is an isolation boundary in Meshes.

You can map a workspace to:

• A customer / tenant
• An environment (e.g. acme-dev, acme-sandbox, acme-prod)
• A product line or business unit

What’s isolated per workspace?

Connections & credentials

OAuth tokens, API keys, and secrets are scoped to a workspace.

Rules & configuration

Event types, routing logic, and transformations are defined per workspace.

Usage & limits

Event counts, connection limits, and rules are tracked per workspace and account.

Audit history

Logs, event history, and failures are visible only for that workspace.

This gives you clean multi-tenancy: each tenant or environment has its own “sandbox” of integrations that can’t see or affect any others.

Connections

A connection is a configured link between a workspace and an external system.

Examples:

• HubSpot connection using OAuth
• Mailchimp connection using API key
• Generic webhook connection to your own service
• Salesforce, Intercom, Slack, or any other supported integration

Types of connections

OAuth-based connections

• Meshes handles the OAuth flow and token refresh.
• Access tokens and refresh tokens are stored encrypted at rest.

API key / token-based connections

• You paste or rotate credentials via the UI or API.
• Keys are stored securely and never exposed in cleartext once saved.

Webhook / HTTP connections

• You configure a URL, method, and optional headers.
• Meshes handles request building, retries, and backoff.

Per-workspace isolation

Connections are never shared across workspaces. If you have three customers each connecting their own HubSpot account, each customer’s workspace gets its own independent HubSpot connection.

Event Types & Resources

Meshes is event-driven.

Event Types

An event type is a named category of event, such as:

• lead.created
• lead.updated
• invoice.paid
• user.signed_up

You define event types per workspace, and then attach rules to them.

Good practices:

• Use dot-separated names (domain.action, object.event style).
• Keep them stable over time so rules don’t need constant renaming.

Resources (payload shape)

Each event carries a payload (the resource) — typically JSON describing the object:

{
  "type": "lead.created",
  "workspace": "acme-prod",
  "payload": {
    "id": "lead_123",
    "email": "jane@example.com",
    "firstName": "Jane",
    "lastName": "Doe",
    "source": "marketing-site",
    "plan": "starter",
  },
}

You can think of “resources” as schema-ish descriptions of your payloads:

• You decide the shape (fields, types).
• You can version them if you need (lead.created.v2 vs lead.created).

Rules

A rule tells Meshes what to do when an event of a given type arrives.

Conceptually, a rule = trigger + conditions + actions.

Triggers

Rules usually trigger on an event type:

• lead.created
• invoice.paid
• subscription.canceled

You can have multiple rules for the same event type, each targeting different destinations or conditions.

Conditions

Optional conditions let you scope a rule further, e.g.:

• Only when resource = "page" and resource_id = "marketing-site"
• Only when resource = "plan" and resource_id = "pro"
• Only for a subset of workspaces or tags (depending on your configuration)

Conditions keep your application code simple: you emit the same event, Meshes decides how to route it.

Actions (fan-out)

Actions define where to send the event and how:

• Send to HubSpot as a contact upsert
• POST to a webhook endpoint
• Push to Mailchimp as a subscriber
• Call an internal HTTP service

For a single event, Meshes can execute many actions in parallel — this is the fan-out engine.

Events & Delivery

Sending events

Your app sends events over HTTPS (or via SDKs) to Meshes.

A typical payload:

{
  "type": "lead.created",
  "workspace": "acme-prod",
  "payload": {
    "id": "lead_123",
    "email": "jane@example.com",
    "source": "marketing-site",
  },
}

Key parts:

• type – the event type name.
• workspace – which workspace the event belongs to.
• resource – (optional) which resource the event belongs to.
• resource_id – (optional) which resource ID that is linked to the resource.
• payload – your business data.

Queues & retries

Meshes handles:

• Queueing – events are accepted and processed asynchronously.
• Retries with backoff – on transient failures (network, 5xxs, rate limits).
• Dead-lettering – when a destination is consistently failing.

Ordering

By default, Meshes does not guarantee global ordering of events across all destinations.

Typical semantics:

• Events are processed asynchronously and may arrive out of order.
• You should design downstream consumers to be idempotent and tolerant of out-of-order deliveries (e.g., by using timestamps or version fields).

Usage & Limits

Meshes tracks usage along several dimensions:

• Events – each event you send into Meshes.
• Workspaces – active workspaces within your account.
• Connections – external integrations configured per workspace.
• Rules – rules configured per workspace and per event type.
• Team members – seats in your account.
• Audit retention – how long logs and event history are stored.

Plan limits (high level)

Each plan defines:

• Included events per month
• Maximum workspaces and connections
• Maximum rules per workspace and per event type
• Audit log retention (days)
• Included team seats

Hard caps vs overages

Currently, Meshes enforces limits with hard caps:

• When you hit your included limit, new events may be throttled or rejected until:
  • The next billing period, or
  • You upgrade to a higher plan.

Enterprise plans can be configured with custom behavior, including soft overages and pooled usage, by agreement.

You can always see your current usage in the dashboard, and you should treat plan limits as guardrails when designing flows (e.g., avoid spamming unnecessary events).