Documentation/Features/AI Triggers

AI Triggers

A personal webhook that wakes your agent when a run finishes. Yours alone, no admin needed, and it does not take the project's shared slot.

What it is

A notification channel belongs to a project, is configured by an admin, and a project has exactly one custom webhook slot. An AI Trigger belongs to you. Everyone on the team can have their own, pointing anywhere, on the same projects, at the same time.

Who can use it

Every member except a guest. No admin permission required.

What it sends

The same signed payload as the custom webhook, plus the trigger id and name.

Where to find it

Settings, then AI Triggers, in the Account group beside MCP Keys.

Project notifications versus AI Triggers

Ownership- a notification channel is shared by the whole project. A trigger is yours, and nobody else can read its secret or its header values.
Who sets it up- a channel needs the integrations permission. A trigger needs no permission at all.
How many- one custom webhook per project. Up to five triggers per person.
Conditions- a channel fires on all runs, failures, or successes. A trigger picks any set of results and any branch pattern.
No message template- the receiver is a machine, so there is no chat line to write.

Choosing projects

Leave the project list empty and the trigger follows every project you can access, evaluated at the moment a run finishes rather than when you saved it. Pick specific projects to narrow it.

Access loss stops delivery on the next run. If you are removed from a project, demoted to guest, or deactivated, the trigger stops firing for you without anyone editing it.

Setting one up

Paste the receiver's URL into Webhook URL.
Add whatever headers it authenticates with. Values are stored encrypted and are never shown again.
Set a body template if the receiver expects a specific shape. Leave it empty to send the standard payload, which already carries the run and project ids.
Press Send test before relying on it.

Worked examples for four common receivers are below, each with the exact headers and body template to paste.

The trigger acts as you. The session runs on the owner's account, and if the agent reads back through the MCP server it sees exactly what the owner's key allows. A teammate's trigger cannot show them more than they could already open in the app.

Governance

An admin can list every trigger in the organization, and disable or delete any of them.
That list shows the destination host only, never the full URL, and no secrets or header values.
A single switch turns AI Triggers off for the whole organization.
An admin cannot edit someone else's trigger, only stop it.

Triggering an AI Agent

Because the payload carries the run identifier, an agent that receives it can pull the failing tests through the MCP server and act on them without polling for anything. Four receivers, in order of setup effort. Each tab below is the whole request- paste the URL into Webhook URL, the header lines into Headers, and the body into Body template under Customize request.

POST https://api.anthropic.com/v1/claude_code/routines/trig_xxx/fire

Authorization: Bearer sk-ant-oat01-xxxxx
anthropic-version: 2023-06-01
anthropic-beta: experimental-cc-routine-2026-04-01

{"text": "run={{run.id}} project={{project.id}} status={{run.status}} {{run.url}}"}

Do not add Content-Type. M00N sets it, along with the X-M00N- headers, and they cannot be overridden.

Claude Code routine

Add an API trigger to the routine, then copy its URL and generate its token. The token is shown once. Both are per routine, each independently revocable, so this trigger holds a narrow credential rather than an account-wide one.

Only text reaches the session, and it is not parsed. Send plain text, not nested JSON- a structured payload arrives as a literal string. Everything the routine needs goes in that one line.
The routine's own prompt must ask for it. Fire text arrives wrapped in a routine-fire-payload block marked untrusted, so a prompt that never mentions it starts a session and does nothing. Write the prompt to say something like "act on the run described in the routine-fire-payload block".
The beta header is dated and rotates. Anthropic keeps the two previous versions working. Copy the current one from the routine's own API trigger panel rather than from this page.
No idempotency. Every delivery starts a new session and draws down that account's usage, so narrow the trigger's conditions rather than firing on every run.

Generic agent

Anything that accepts a plain JSON POST. Leave the body template empty and the standard payload goes as-is, carrying runId, projectId and the stats. Set a signing secret and verify it- see Notifications for the payload shape and a worked verification example.

GitHub Actions

A repository dispatch starts a workflow that listens on on: repository_dispatch, which reads the fields back from github.event.client_payload. The token needs repo scope.

client_payload allows at most 10 top-level properties and the whole body must stay under 64 KB.

Automation platform

A workflow builder such as n8n, Zapier or Make gives you a URL and starts the job on any POST. The URL is itself the credential, so there is usually no header to add- set a signing secret instead and check it in the first step of the workflow.

A useful last step for the agent itself: have it attach its own session back to the run as an external link, so the analysis is one click away from the run it explains.

Deliveries are sent once and are not retried, so treat a missed delivery as possible and make your receiver idempotent on X-M00N-Delivery.

Notifications- the shared, project-level channels, the signature your receiver verifies, and the full list of template variables.

← Notifications Settings & Admin →

Last updated 21 August 2026