One endpoint.131 operations.

Calling a capability

Every operation goes through one dispatcher. The capability name is the path; the body is its input.

curl -X POST https://app.beaam.app/api/v1/list-stacks \
  -H "Authorization: Bearer $BEAAM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{}'

Create a key under Settings → API keys. Responses share one envelope, so a client written once works for every capability:

{ "ok": true,  "data": { ... } }
{ "ok": false, "error": { "message": "..." } }

The machine-readable source of this page is/api/v1/manifest — fetch it to generate a typed client rather than writing one by hand.

Prefer Postman? The downloadable collection groups every operation by category and includes example JSON bodies. After importing it, set the apiKey collection variable to a key from Settings → API keys; public operations need no key.

Generating a client, or importing into Insomnia, Bruno or an API gateway? TheOpenAPI 3.1 documentcarries every operation's input and response schema, the shared error envelope, and a note on each operation that can refuse in-band — so a generated client is told to checkdata.status, not just the HTTP status. It is generated from the same manifest as this page, on the same date.

Badges. read-only makes no changes ·destructive changes or removes something you already have ·mcp is exposed to assistants through the MCP connector ·public needs no authentication.

Same operations, other surfaces

Because these come from one registry, the MCP connector exposes the same operations to an assistant, and anything added to Beaam appears on every surface at once rather than being ported to each.