Skip to main content
The MeshAgent REST API exposes administrative and lifecycle operations for projects, rooms, users, permissions, services, storage, billing, sessions, and project settings. The REST API can be used for:
  • Projects & Rooms: Create projects, manage rooms, and mint room connection tokens
  • Resource policies: Manage access to rooms, repositories, feeds, service accounts, and other project resources
  • Project storage: Upload/download project files by path
  • Services: Manage project-wide and room-scoped services
  • Secrets: Manage user-owned and service-account-owned credentials
  • Project settings & integrations: Update project settings, model routing configuration, webhooks, API keys, and OAuth clients
  • Shares: Create share links for Rooms
  • Mailboxes: Manage mailboxes mapped to Rooms
  • Operations: Understand sessions (events/spans/metrics) and create/manage scheduled tasks
  • Billing & usage: Get insight into your account balance, transactions, subscriptions, and usage reporting
For room-specific operations such as working with agents, datasets, or queues use the Room APIs.

Getting started

To call the MeshAgent REST API, authenticate with a project API key. The simplest path is:
  1. Set up a Python environment with the MeshAgent SDK installed (requires Python 3.13)
  2. Use the MeshAgent CLI to create and activate an API key, then store it in a .env file
  3. Load the key from .env and create a Meshagent() client
MeshAgent requires Python 3.13. We recommend using uv, which manages Python versions, virtual environments, and dependencies automatically. To learn more about uv see the Machine Setup Guide for Python

1. Set up the SDK

Install uv, then create a project and virtual environment with MeshAgent installed:
Activate your virtual environment:
Note: You’ll know your virtual environment is active when you see (.venv) at the start of your terminal prompt. When the environment is activated, you can run commands directly (e.g. meshagent setup or python main.py). If the environment is not activated, prefix commands with uv run (e.g. uv run meshagent setup or uv run python main.py).
To upgrade dependencies later, run:

2. Create a new API key and store it in .env

Create a .env file in your project and paste the key value:

3. Create a MeshAgent client

Now we can create the MeshAgent client and use it to do something like list all the rooms in our project.

Client configuration

The Meshagent() client accepts a base_url and token.
  • base_url: defaults to MESHAGENT_API_URL (defaults to https://api.meshagent.com)
  • token: a bearer token for the Authorization header.
    • This will default to MESHAGENT_API_KEY. API keys are scoped to a specific project, so most REST calls will also require a project_id.
REST calls raise meshagent.api.RoomException on non-2xx responses. Many methods also validate responses with typed models, while others still return plain JSON dicts or lists directly.

Projects, Rooms, and managed agents

Create and manage projects, Rooms, and managed agent identities. Room and agent connection methods return signed connection information for the target runtime. Project settings are independent documents named openai, anthropic, otel, admission, room, and room_roles. They are stored in project storage under .meshagent/settings/ as one JSON file per group (for example, .meshagent/settings/openai.json). The REST path and storage filename for room_roles use room-roles; SDK clients translate that name automatically. A missing document is unconfigured and is not read from the legacy project settings field or any database fallback.

User profiles

A project user profile combines shared account defaults with overrides stored for that project. The same account can have different names, metadata, and annotations in different projects. ID and email remain account identity fields and cannot be edited through profile updates.

Read views

GET /accounts/projects/{project_id}/users and GET /accounts/projects/{project_id}/users/{user_id}/profile accept view=project|user|merged. Use me for the signed-in user. Metadata and annotations merge by key; a project key replaces the global value, including an entire nested metadata value. Global values remain visible wherever the project has no override. All three views require project membership and an OAuth token covering the project with projects:iam.read. The legacy admin scope and projects:iam.write also cover reads. A requested user must belong to the project. Project API keys can read users in their project. The account endpoint, GET /accounts/profiles/me, requires profile:read and is self-only. To read another user’s shared profile, use an authorized project endpoint with view=user, or a sysadmin endpoint.

Editing project overrides

PUT /accounts/projects/{project_id}/users/{user_id}/profile always edits project-local overrides. Every edit requires user_profile_editor, including editing your own project profile, and a token covering the project with projects:iam.write (legacy admin is accepted). Project owners and admins inherit the editor role. The target must belong to the project.
Send only changed fields. Supplied maps replace the project’s stored map; omitted fields are preserved. {} clears the local map, revealing global defaults. Annotation values must be strings; metadata values may be arbitrary JSON. Name fields accept strings or null. Email, IDs, and roles are not editable through this endpoint. To restore inheritance, send inherit, containing field names to remove from the project profile:
A field cannot be both supplied and inherited in the same request. Project profile editors should load view=project for editing and view=user to show inherited defaults. Saving the merged view would copy defaults into project overrides.

Editing global defaults

PUT /accounts/profiles/me requires profile:write and lets users edit their own global names and metadata. It cannot edit global annotations or another account, even when the caller has a project editor role. Project edits never write the global profile. Sysadmins use these dedicated endpoints: All sysadmin endpoints require both the OAuth sysadmin scope and registered sysadmin membership. A scope alone does not grant platform authority. Global annotations are edited only through these endpoints. Global profile data returned to projects is shared data; keep private account settings outside these profile maps. Successful updates return {"ok": true}. Invalid views, JSON, fields, or inheritance requests return 400; missing permissions return 403; missing profiles return 404.

Python SDK examples

Resource policies

Managed agent resource policies are not supported. Use service-account run_as configuration for agent access, and use resource policies for supported resource types.

Project Storage

MeshAgent allows you to use both project wide and room specific storage. For room-scoped storage see the Storage API documentation.

Services

Create and manage project and room services. Project services are available to all rooms in your project while room services are scoped to a specific room.

Project Services

Room Services

Secrets

Secret workflows use user-owned and service-account-owned secrets; see Secrets and Credentials.

Routes

Create and manage project routes that map domains to rooms, ports, and route specs.

Feeds and subscriptions

Create project feeds, publish messages, and fan them out into room storage through subscriptions.

LLM loggers

Create project LLM loggers that copy LLM proxy events into destination feeds. Use these when you need a feed-backed stream of LLM request metadata for processing or analysis.

Registries

Create and manage project-owned image repositories.

Webhooks

API Keys

OAuth clients

Manage OAuth Clients for connections with other services.

External OAuth registrations

Manage project and room external OAuth registrations. These records are separate from project OAuth clients: OAuth clients let your app authenticate users through MeshAgent, while external OAuth registrations connect MeshAgent-managed integrations to external OAuth providers.

Shares

Manage share records for a project.

Mailboxes

Create and manage mailboxes that can be used by Agents or Rooms. Delivery routes require mailboxes:read plus the project mailbox_inventory relation. They are not room-scoped, and the response does not repeat the mailbox address because it is already part of the request path. Project API keys retain project-wide access.

Delivery status API

GET /accounts/projects/{project_id}/mailboxes/{address}/deliveries returns one current delivery record per recipient. Results are newest first and the response has the shape { "deliveries": [...], "total": number }. It accepts: GET /accounts/projects/{project_id}/mailboxes/{address}/deliveries/{delivery_id} returns { "delivery": {...} }. The record contains the current status, submission and recipient identifiers, status timestamps, attempt count, and the latest available SMTP, MX host, TLS, and failure details. GET /accounts/projects/{project_id}/mailboxes/{address}/deliveries/{delivery_id}/events returns { "events": [...], "total": number }. It accepts count and offset, and returns events in chronological order. The normalized event types are accepted, temporary_failed, delivered, and permanent_failed; their resulting delivery statuses are accepted, deferred, delivered, and failed, respectively. Each event includes its occurrence and receipt times, provider event ID, resulting status, and any provider-supplied attempt, SMTP, MX host, TLS, certificate, reason, and description fields.

Sessions

Inspect active/recent sessions and fetch diagnostics, or terminate sessions.

Scheduled Tasks

Scheduled tasks let you automate room workflows by sending queued messages on a schedule (cron or one-time).

Billing & usage

Checkout balances, transactions, subscriptions, and usage reports.

What’s next?