- 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
Getting started
To call the MeshAgent REST API, authenticate with a project API key. The simplest path is:- Set up a Python environment with the MeshAgent SDK installed (requires Python 3.13)
- Use the MeshAgent CLI to create and activate an API key, then store it in a
.envfile - Load the key from
.envand create aMeshagent()client
MeshAgent requires Python 3.13. We recommend usinguv, which manages Python versions, virtual environments, and dependencies automatically. To learn more aboutuvsee the Machine Setup Guide for Python
1. Set up the SDK
Install uv, then create a project and virtual environment with MeshAgent installed:Note: You’ll know your virtual environment is active when you seeTo upgrade dependencies later, run:(.venv)at the start of your terminal prompt. When the environment is activated, you can run commands directly (e.g.meshagent setuporpython main.py). If the environment is not activated, prefix commands withuv run(e.g.uv run meshagent setuporuv run python main.py).
2. Create a new API key and store it in .env
.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
TheMeshagent() client accepts a base_url and token.
base_url: defaults toMESHAGENT_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 aproject_id.
- This will default to
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 namedopenai, 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.
{} 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:
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-accountrun_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?
- Explore the Room API overview to work with live collaborative rooms.
- Review the
ApiScopereference for details on permission shape. - Learn how room connections inherit grants in participant tokens.