Skip to main content
Swarm exposes one user-facing API: JSON-RPC 2.0 over HTTP for request and response, and JSON-RPC subscriptions over WebSocket for live streams. One transport, one auth model, one request/response shape. The swarm CLI, channel packs, and any custom client all route through it. Method pages are generated from the platform’s method catalog, so they track the runtime exactly.
Every method is a single POST /v1/rpc with the method name in the JSON-RPC body. The per-method paths in this section (for example POST /v1/rpc/event.publish) are a documentation convenience so each method gets its own page. See Transport and auth for the real envelope.

​
Method groups

run.start remains available as a deprecated wrapper with event.publish semantics; new clients should call event.publish directly (it allocates a run when none is given).

​
Conventions at a glance

  • Auth: a bearer token on every HTTP request and the WebSocket upgrade.
  • Pagination: cursor-based; list methods take limit and cursor and return next_cursor.
  • Idempotency: mutating methods accept an idempotency_key.
  • Versioning: the surface is under /v1/; breaking changes bump to /v2/.

​
Not in v1

A few things a client should plan around, because v1 deliberately does not have them yet:
  • No multi-tenancy. There is no org_id, tenant_id, or workspace_id; one deployment is one tenant. A tenant prefix is reserved in the URL shape for later, so a future version can add it without breaking v1 URLs.
  • No rate limiting and no SLA. Requests are not throttled in v1. A RATE_LIMITED error code is reserved for later, so tolerate it as a possible future response.
  • No bulk or batch endpoints. Each mutation is its own call; there is no multi-item request.
Browse the methods in the sidebar, or start with Transport and auth and Subscriptions.