Integrations: MCP, API, webhooks, CLI

The hub for everything outside the browser: the REST API, personal access tokens, the MCP server, the agent API, the change webhook, aiopsctl and the webhooks.

Concept · Updated 2026-10-17 · Describes release 0.1.164

What these pages are for

Everything outside the browser talks to your tenant through one of four doorways.

Doorway Endpoint Used by Credential
REST API /api/aiops/{tenant_id}/… scripts, dashboards, CI, your own portal personal access token
MCP server /mcp/aiops any MCP-capable AI client personal access token
Agent API (OpenAI-compatible) /api/aiops/{tenant_id}/agents/{pillar}/v1/… OpenAI SDKs, evaluation harnesses personal access token
Alert webhooks /webhook/{source}/{slug} Alertmanager, Grafana, Datadog, Dynatrace, CloudWatch, Azure Monitor, Robusta, plus a generic adapter for anything else webhook token

The first three share the same personal access token. The webhooks use a separate, tenant-wide ingest token, because an alert source is a machine that should never be able to read your incidents.

All of it is configured on one page: Settings · Data in → Alert intake & tokens (route /portal/tokens). Notification targets moved off it — those live under Settings · Account → Notifications & on-call. /portal/webhook and /portal/agent-api are legacy links that redirect there.

The pages

The chapter that used to live at this address is now the pages below, in the order its sections had.

Webhooks

Alert sources, posture scanners, ticket systems and change sources post to https://<your-host>/webhook/<source>/<workspace-slug> with the workspace's webhook token, in a header wherever the source allows it. Which source configures what, the token forms, each adapter's payload and status mapping, the response counters and the error strings are in the Webhook reference; minting the token is Create the webhook token, and each observability platform step by step is Alerts from your observability platform.

Next steps