One feature,every way in.

Beaam does not have a dashboard with an API bolted on. Each feature is defined once, and the web app, the API and your assistant all call that same definition.

One operation, defined once

Everything Beaam does — listing your services, connecting a provider, acknowledging an incident, changing a threshold — is a namedoperation with a declared input and output. There are currently 131 of them. Each one is written once, and every way in calls that one definition:

  • The web app calls it directly from the server that renders the page.
  • The HTTP API serves it at POST /api/v1/<name>.
  • An AI assistant calls it as a tool through Beaam's hosted MCP connector.

There is no second implementation for any of them to drift away from. A new feature arrives on the API and in the assistant connector the moment it exists, rather than being ported later — and when one changes, it changes everywhere at once.

Why that matters to you

  • Scripts see what the screen sees. The API returns what the web app shows, because both read it the same way. Nothing is available only behind a button.
  • Automation is not second class. Connecting a provider, setting the watchlist, scheduling a maintenance window — the operations you would reach for in a deploy script are the same ones the web app uses.
  • Your assistant is calling the product. It is not reading a scraped dashboard. An answer about an incident comes from the same operation the history page uses.
  • The rules hold everywhere. Input is validated, and plan limits checked, inside the operation itself — so a request from a script is refused, or allowed, exactly as the same action in the browser would be.

The ways in

Way inWhereHow it authenticates
Web appapp.beaam.appYour signed-in session
HTTP APIPOST https://app.beaam.app/api/v1/<name>An API key, sent as a bearer token
AI assistant (MCP)https://app.beaam.app/api/mcpOAuth 2.0 — you approve the connection in a browser

A command-line client built on the same operations is in development and not yet released.

Authentication on each

Web app

Signing in gives your browser a session, and every page acts as you, in your active organization. Nothing further to set up.

HTTP API

Create a key under Settings → API keys and send it on every request:

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

The full key is shown once, when you create it — Beaam keeps only a hash, so copy it then. You choose an expiry or none, and any key can be revoked from the same screen. A key is bound to the organization it was created in and cannot be used to act in another. The response envelope, error shape and how to name an organization explicitly are inAPI conventions; every operation and its schema is in the API reference.

A small number of operations are public and need no key at all — reading the integration catalog is one. The API reference marks them.

AI assistant

Add https://app.beaam.app/api/mcp as a remote MCP server in your assistant's connector settings. It is hosted by Beaam, so there is nothing to install. The first time the assistant touches your account it opens a browser, you sign in to Beaam and approve the connection, and the tools appear. Authentication is OAuth 2.0 with PKCE and dynamic client registration — no key to paste, nothing long-lived sitting in a config file.

A connection carries read and writeaccess by default. A client that asks only for read access can call read-only tools and nothing else. Every connected assistant is listed on the Assistant page in the web app, andDisconnect ends that one's access immediately without affecting the others. Setup for specific clients is onAssistant (MCP).

Tool names are the operation names with underscores:list-services on the API is list_services to an assistant. An MCP client that cannot do OAuth can send an API key as a bearer token instead.

The manifest is the contract

The list of operations is published, not just documented:

curl https://app.beaam.app/api/v1/manifest

It needs no key. For every operation it gives the name, a title and an end-user description, its category, whether it needs you signed in, whether it is read-only or destructive, whether it is offered to assistants, and a JSON Schema for both its input and its output. The assistant connector builds its tool list from this, and theAPI reference is generated from it — so neither can describe an operation that does not exist, or miss one that does. Fetch it to generate a typed client rather than writing one by hand.

Tooling Beaam uses to operate the service itself is not part of this surface. It does not appear in your manifest, and calling it answers exactly as an operation that does not exist would.

What assistants are not given

Of the 131 operations, 91 are offered to assistants and 40 are deliberately withheld. The withheld ones fall into a few categories:

  • Billing and payments — starting, cancelling or resuming a subscription, checkout, payment history. An assistant cannot spend or stop spending your money.
  • Credentials — creating, listing or revoking API keys, and revealing or rotating signing and ingest secrets. A long-lived credential should be issued by you, not handed to a conversation.
  • Organization and account administration — members and invitations, creating, renaming, switching or deleting organizations, deleting your account or wiping its data.
  • Disconnecting assistants. An assistant can see its own connection but cannot revoke one — otherwise it could revoke itself mid-conversation, and the next call would fail with nothing left able to explain why.
  • Publishing — turning your public status page on or off.
  • Page plumbing — a few operations that exist to assemble a single web page in one request, and would only duplicate tools the assistant already has.

Withholding applies to the assistant connector only. Everything in that list is still yours to use in the web app and over the API with your own key. The mcp badge in the API reference shows which operations an assistant gets.

Read-only, destructive, and the outside world

Every operation declares what it does to your account, and the same declarations reach every way in — they are in the manifest, they are the badges in the API reference, and they become the hints an assistant reads before calling a tool.

MarkMeansExamples
Read-onlyMakes no changes.Listing services, reading incident history
WriteAdds something without changing what you already have.Connecting a provider, creating a stack, adding an incident note
DestructiveChanges or removes something you already have.Changing a threshold, renaming a stack, deleting an integration
Reaches outside BeaamCan cause something visible beyond your account.Sending a test alert to email, SMS, Slack or a webhook

A compliant assistant asks you before running anything destructive, and treats read-only tools as safe to call while answering a question. The last mark is independent of the others: a test alert adds nothing you would call a change, but it does reach the outside world, so an assistant is told so.

Questions

Is the API a separate product from the web app?

No. The web app is built on the same operations the API serves, rather than on its own copy of them. A threshold changed over the API is the same change, validated the same way, as one changed in the browser — and plan limits are checked inside the operation, so they apply identically whichever way you call it.

Can my assistant do everything I can?

Nearly. Billing, credentials, organization and account administration, and a few page-assembly operations are withheld from the assistant connector on purpose. They are not removed from Beaam: you can still reach them in the web app and over the API with your own key.

Can an assistant delete something without asking me?

Operations that change or remove something you already have are marked destructive, and a compliant assistant asks you before running them. Beaam sets the mark; asking is the assistant's behaviour. You can also connect an assistant with read access only, which limits it to read-only operations, and disconnect any assistant from the Assistant page at any time.

Do API keys expire?

You choose when you create one: no expiry, or a fixed lifetime. The full key is shown once, at creation, and Beaam stores only a hash of it, so a lost key is replaced rather than recovered. Any key can be revoked from Settings → API keys.

Which organization does a request act in?

An API key or an assistant connection is bound to the organization it was created in. A signed-in browser session acts in your active organization. API conventions covers naming an organization explicitly.

Is there a command-line client?

One is in development and not yet released. Until it is, anything you would script from a terminal is a single HTTP request to the API.