# Meshes > Meshes is a universal event routing and integration platform for SaaS applications. It replaces hand-rolled integration code with a single API that routes product events (signups, payments, user actions) to tools like HubSpot, Salesforce, Intercom, Mailchimp, Slack, Webhooks, and more — with automatic retries, fan-out, and multi-tenant workspace isolation. Canonical: https://meshes.io/llms-full.txt Short index: https://meshes.io/llms.txt Last updated: 2026-09-06 Meshes is designed for solo developers and engineering teams at SaaS companies of any size who currently maintain custom integration code. Instead of building and maintaining webhook delivery, retry logic, OAuth token management, and field mappings for each destination, teams emit events once and Meshes handles routing and delivery. The platform is a full integration layer — not just webhook delivery, but complete connection management with built-in OAuth token handling, field mappings, multi-tenant workspace isolation, and an embedded workspace product for customer-facing SaaS applications. --- ## Core Concepts Meshes has four primitives: ### Workspace A tenant-scoped container. Each workspace has its own connections, rules, event history, and a publishable key. Recommended pattern for multi-tenant SaaS: one workspace per customer tenant. Workspaces provide complete isolation between tenants. ### Connection A configured destination within a workspace. Examples: a HubSpot OAuth connection, a Salesforce API key, a webhook URL. Connections store destination auth/config metadata and expose available actions. Each connection specifies an integration type and stores the authentication details needed to communicate with the destination. ### Rule A routing rule that binds an event type to a connection action. Rules typically include `workspace`, `connection`, `event`, optional `resource` and `resource_id` filters, and a `metadata` object with at minimum an `action` field that determines what the destination does (e.g., `add_to_list`, `create_or_update_contact`, `send_webhook`). ### Event A JSON payload emitted by your application (e.g., `user.signup`, `payment.failed`, `lead.created`). Events are routed to matching rules within a workspace. Each event tracks delivery status across all matched rules with `rule_events`, providing full observability into what happened with each delivery attempt. Event and rule status use the same vocabulary: `pending`, `processing`, `retrying`, `completed`, `failed`, `canceled`. Every delivery attempt is recorded with timing and a structured `outcome_code` (such as `delivered`, `rejected_server_error`, `rate_limited`, `auth_failed`, `timeout`, `network_error`, `mapping_error`). Authorized users can cancel a single rule or an entire event, and can force the next attempt immediately for a rule in a retry loop. --- ## API Architecture ### Base URLs - OpenAPI server / base URL: `https://api.meshes.io/api/v1` - Browser-friendly event ingestion alias: `https://events.meshes.io/api/v1` (CORS-enabled, for `POST /events` and `POST /events/bulk`) ### Authentication Meshes supports two authentication methods: #### Bearer Token (Management API) For server-side operations — managing workspaces, connections, rules, and reading events. Uses short-lived HS256 machine JWTs (maximum 60 seconds). JWT conventions: - `kid` header uses access key - `iss` is `urn:meshes:m2m:` - `aud` is `meshes-api` - `org` is organization UUID The `@mesheshq/api` SDK handles token generation automatically. ```typescript const headers = { Authorization: 'Bearer YOUR_JWT_TOKEN', 'Content-Type': 'application/json', }; ``` Never expose machine access keys or secret keys in frontend code. #### Publishable Key (Event Ingestion) For emitting events — safe to expose in frontend code and public repositories. Sent via the `X-Meshes-Publishable-Key` header. Only grants access to `POST /events` and `POST /events/bulk`. Each workspace has its own publishable key, returned when you `GET /workspaces/{workspace_id}`. ```typescript const headers = { 'X-Meshes-Publishable-Key': 'pk_live_...', 'Content-Type': 'application/json', }; ``` For browser-based event emission, use `https://events.meshes.io` (CORS-enabled) instead of `https://api.meshes.io`. #### Session Token (Embedded Workspace Runtime) For the embedded workspace product, your backend can mint a workspace-scoped session token from the private management API. This token is not a replacement for machine authentication in your backend. It is a short-lived runtime credential used by the iframe after bootstrap. Embedded sessions also return a `launch_url`: - `launch_url` bootstraps the initial iframe document request - the session token is sent later with `postMessage` - a hard iframe reload should use a fresh `launch_url` ### Pagination List responses use cursor-based pagination with a standard envelope: - `count` — number of records in this page - `limit` — page size - `next_cursor` — cursor for the next page (null if no more) - `records` — array of results Some list endpoints accept `cursor` and `limit` query params. --- ## Embedded Workspace and Session Layer Meshes also supports embedding selected workspace pages inside your own application with an iframe-based runtime. ### Supported Embedded Pages The current supported embed surface is: - dashboard - connections - rules - events - event detail - connection mappings `members` and `settings` remain web-only. ### Two-Step Bootstrap Model The embed runtime uses two related credentials: 1. **Launch URL / launch token** - short-lived - used only for the initial iframe request 2. **Session token** - workspace-scoped runtime credential - sent to the iframe after it loads - used for the authenticated workspace experience Typical host flow: 1. backend calls `POST /api/v1/sessions` 2. backend returns `launch_url` and `access_token` to the frontend 3. frontend renders `