Connect tools and notification delivery

All responder configuration writes use the server preview and confirmation flow in both MCP and the CLI. Discover the action with list_write_actions, call its declared door without confirm_token, and review the complete before, proposed, required scopes and external audience. After approval repeat identical arguments, adding the returned token. CLI commands omit --confirm-token for preview and repeat with it to apply; there is no local --yes bypass.

Creates require a stable idempotency_key in MCP or --idempotency-key in the CLI. Keep it identical in preview, confirmation and retry. Identical creates return the first committed result; a different request under the same key is refused. One-time signing and heartbeat secrets are withheld on durable replay. Updates of schedules, contact methods, escalation policies and channels require the exact current updated_at as expected_version / --expected-version. Incoming-source edits and secret rotations require the current positive source version in that field. Template versions and catalog and monitor revisions keep their numeric fences. A conflict needs a new read, preview and approval.

Connections authorize Anectico to interact with another product. Notification channels define a concrete delivery destination used by alert rules. A connection alone does not route any alert.

A channel test that fails delivery is a negative outcome. The CLI prints the complete failure detail and exits 1, including JSON output; a successful request alone does not prove the notification arrived.

Repeated delivery of the same Slack interaction returns its original result without repeating its action or undoing a later change. An issue snooze keeps the deadline set by the signed interaction; a delivery retry does not extend it. Each action still requires your current permissions.

Where to do it

In the Console, open Connections and notifications (/connections). The page has two tabs:

• Connections holds your connected services, such as Slack, GitHub, Jira, Linear, PagerDuty and Telegram.
• Notifications holds your Notification channels and your own My contact methods.

See the Console guide. A sign-in at another service, a bot token and a routing key are secrets that a person gives, so they are set here. The menu shows this page to you only if you hold connections:read or channels:read.

Ask your agent

"List my connections and tell me which one needs reauthorization."

"Create a webhook notification channel for the platform team, then send a test through it."

Job	MCP tool or action	CLI command
List connections or read one	list_connections, get_connection	anectico connections list, anectico connections get <connection-id>
Ask a person to connect Slack, GitHub, Jira or Linear	request_oauth_handoff, then get_oauth_handoff	anectico connections oauth handoff <provider>, then anectico connections oauth status <handoff-id>
Store, rotate or delete a token-based connection	create_connection, update_connection, delete_connection	anectico connections create, anectico connections update <connection-id>, anectico connections delete <connection-id>
Map a Slack user to a member	list_identity_mappings, map_external_identity, unmap_external_identity	anectico connections mappings list, set, delete
List, create, change, test or delete a notification channel	list_notification_channels, get_notification_channel, create_notification_channel, update_notification_channel, test_notification_channel, delete_notification_channel	anectico channels list, get, create, update, test, delete
Read or change a channel template	get_effective_notification_template, list_notification_templates, get_notification_template, create_notification_template, update_notification_template, delete_notification_template	anectico channels templates effective, list, get, create, update, delete
Manage your own contact methods	list_contact_methods, create_contact_method, update_contact_method, delete_contact_method	anectico oncall contact-methods list, add, update, delete
Read delivery history	list_notification_deliveries, get_notification_delivery	anectico deliveries list, anectico deliveries get <delivery-id>
File, read or unlink an external ticket for an Issue	create_ticket, get_ticket, list_tickets_for_issue, unlink_ticket	anectico tickets create <issue-id> --provider <provider> --issue-url <issue-url> --idempotency-key <key>, anectico tickets get <ticket-id>, anectico tickets list <issue-id>, anectico tickets unlink <ticket-id> --yes

Reads of connections need connections:read. Changes need connections:write, and a delete needs connections:delete. Tickets need a connected tracker plus tickets:read, tickets:write or tickets:delete, and errors:read. Channels use channels:read, channels:write and channels:delete. The MCP write tools preview first; see MCP tools for the confirm step. A provider's consent step always needs a person, as the section below explains.

What your agent gets back

Reads are secret-safe. A connection read says whether a credential is stored and which version a rotation must quote, and it never returns the credential. A channel read shows routing only: the email recipients, the Slack channel, a webhook's method and header names. The webhook URL and every header value are hidden. A delivery read returns operational metadata, never the rendered message. These pages have no proof page; the Console page above is where you check the result.

Connect an external tool

On the Connections tab, choose a provider:

• Slack, GitHub, Jira, and Linear use an authorization flow;
• PagerDuty accepts an Events API v2 routing key;
• Telegram accepts the token of a bot you create.

Connection settings can choose a repository, project, or team within a provider. They cannot change the provider's API address: base_url is rejected by connection create and update requests. Custom API addresses require deployment administrator configuration. Ticket API requests fail if the configured endpoint returns a redirect.

Slack's authorization asks for permission to post messages, create, rename and read channels, and pin messages — the channel and pin permissions are what let an incident open (or link) a dedicated Slack channel with a pinned, always-current summary (see Work an incident in Slack).

For PagerDuty, create or choose a service in Services → Service Directory, add an Events API V2 integration, and paste its Integration Key into Anectico. Use the service's routing key, not a PagerDuty REST API access key. The current sender supports PagerDuty's US region only. Each customer supplies the key for their own service; no shared Anectico PagerDuty account is required.

PagerDuty delivery currently creates trigger events only. Acknowledging or resolving an alert in Anectico does not acknowledge or resolve its PagerDuty incident, and changes in PagerDuty do not sync back. Manage the PagerDuty incident there. Testing a channel creates a real incident; resolve it after verification.

When acknowledgment is withdrawn or a silence expires, another trigger for the same Anectico alert updates its existing open PagerDuty alert, provided the routing key is unchanged. If the problem resolves and later creates a new Anectico alert, that alert has a separate identity in PagerDuty, even when the rule and problem are the same. PagerDuty can create a new alert if its previous alert was already resolved there.

PagerDuty alert titles are limited to 1,024 characters. Anectico shortens longer titles with an ellipsis and includes the rendered title and message in the event's custom details. Each detail is kept up to 16 KiB of text; longer details also end with an ellipsis. Long alert content can therefore still reach responders without exceeding the title limit.

For Telegram, alerts are posted by your own bot. In Telegram, open a chat with @BotFather, send /newbot, and follow the prompts. Paste the token it gives you into the Telegram provider on the Connections tab. Anectico checks the token with Telegram before saving it and never displays it again. Anyone who holds the token can post as the bot, so treat it like a password; if it leaks, issue a new one with /revoke in @BotFather and replace the connection's credential.

You can connect more than one Telegram bot — for example one per team — with Add another bot. Give each a display name; that name is how you choose a bot when you create a channel. Removing a bot stops every channel that posts as it until you point those channels at another bot.

Connect from the CLI or an agent

A provider's consent always happens in a person's browser, so a script or AI agent asks a person to finish it:

anectico connections oauth handoff slack          # prints handoff_url and handoff_id
anectico connections oauth status <handoff-id>    # completed shows the new connection_id

Give the handoff_url to a member who can manage connections. It opens a Console page at /connections/handoff/.... They sign in to Anectico, see which provider was requested and by whom, and choose Continue to consent at the provider. Any setup given with --metadata is fixed when the link is created and cannot be changed by whoever opens it. The link can be opened for 24 hours. Once someone continues, they have 15 minutes to finish at the provider. status reports awaiting_human, authorizing, completed, failed or expired, and only completed means a connection was made. An API key can request a handoff but cannot finish one. An MCP agent uses request_oauth_handoff and get_oauth_handoff.

Complete the provider flow, return to Anectico, and confirm the provider shows Connected. A Needs reauth state means the saved authorization can no longer be used. Choose Reauthorize to replace its OAuth grant in place; linked tickets remain pinned to that connection. Disconnect a provider only after checking alert routes and linked ticket workflows that depend on it.

For Slack specifically, this state is labeled Reinstall needed rather than the generic Needs reauth: it almost always means the app was installed before Slack incident channels existed and is missing the permissions that feature needs (managing and reading channels, and pinning messages), not that the authorization expired. Choose Reinstall to grant them, then create or link the Slack channel again on any incident whose channel stopped updating: the incident picks up where it left off and reuses its channel when that channel still exists.

Except for Telegram, where several bots are expected, if Anectico detects more than one non-revoked connection for a provider, the page shows Connection conflict with every exact connection ID and status; it does not hide a broken connection behind an active duplicate. Disconnect the unintended duplicate before choosing Reauthorize on the connection that existing tickets use.

Jira setup asks for the target project key, issue type, optional priority, and any required customfield_N values before redirecting to Jira. Linear setup asks for the team plus the open and done workflow-state IDs. These values are non-secret connection metadata and survive the OAuth callback; access and refresh tokens remain write-only. Reauthorization pre-fills the current setup so you can rotate authorization without silently changing the ticket destination.

For Jira status changes to sync back, a Jira administrator must also create a signed webhook in Jira settings → System → Webhooks. Select issue-created and issue-updated events, filter to the connected project, and use the URL shown in Configure status sync on the Jira provider of the Connections tab. Generate a random signing secret of at least 20 characters and save the same value in both places. Anectico encrypts it and never displays it again. Delete the Jira webhook when disconnecting. This additional setup is required for Jira; authorizing OAuth alone enables outbound ticket actions. Jira status-sync events retain only the issue key and status category in the event stream. Profile names, emails, comments, and other original webhook fields are removed before storage. A restricted account-reference inventory supports Atlassian personal-data reporting and erasure; disconnecting Jira removes that connection's retained references. Linear's app webhook is installed with workspace authorization and needs no customer signing secret.

Credential rotations are validated before Anectico replaces the current credential. If another admin rotated it first, refresh and retry against the new version; an invalid or stale update leaves the last working credential untouched. Disconnect is an idempotent revocation. Deletion and status revocation destroy stored access, refresh and signing credentials, clear provider setup and cancel related authorization state. A terminal audit row remains with no secret material. Revocation cannot be undone; create a new approved connection before retrying the route. Requests already sent to the provider and their own copies are outside this deletion.

Deleting your organization erases every stored connection credential and the delivery history that refers to it. Before erasing, Anectico makes a time-limited attempt to revoke active Slack access tokens and Linear access and refresh tokens, and to uninstall an active GitHub App installation. A provider failure does not prevent local erasure. These attempts are best-effort, not a guarantee that all provider access has ended; an accepted uninstall can still be pending.

Check the provider's settings and remove any remaining Anectico authorization yourself. This is especially important for disconnected or Needs reauth connections, manually supplied keys, and Slack app installations or refresh grants. The workspace or installation in an old connection may now be used by another Anectico organization, so the old authorization is not automatically revoked. Jira authorization and the signed webhook you created in Jira must be removed there manually. Only remove a shared installation when no other organization still needs it. Deleting a project erases only that project's incoming alert sources and does not revoke organization-level provider access.

Create a notification channel

In the Console, open Connections and notifications (/connections), choose the Notifications tab, and use the Notification channels card. Create a channel for webhook, Slack, email, PagerDuty, or Telegram delivery. Select the connected provider or enter the required destination, save, then test the saved channel. Your agent can do the same with create_notification_channel and test_notification_channel (CLI: anectico channels create and anectico channels test <channel-id>).

Email, Slack and webhook channels can also receive a scheduled report of a saved insight or dashboard; pick them as recipients when you create the report.

Send alerts to a Telegram chat

A Telegram channel needs the Telegram connection above and a chat the bot can post in:

1. Add the bot to the group or channel that should receive alerts. In a channel, make it an administrator with permission to post. For a private chat with one person, that person must open the bot and press Start first — a bot cannot message someone who has not.
2. Find the chat ID. Send any message in the chat, then open https://api.telegram.org/bot<your-token>/getUpdates in a browser and read chat.id. Group and channel IDs are negative, for example -1001234567890. A public channel or group can use its @username instead.
3. Create the channel with type Telegram and that chat ID. If several bots are connected, choose which one the channel posts as under Bot; with a single bot it is selected for you. To post into one topic of a group that has topics enabled, also enter the topic ID (message_thread_id in the same response).
4. Test the channel. A short confirmation message appears in the chat.

From the API, CLI or an agent, the channel config is {"chat_id": "-1001234567890", "connection_id": "<telegram connection id>", "message_thread_id": 42}. connection_id is the ID of the Telegram connection (bot) to post as, as listed by anectico connections list --provider telegram; the topic is optional. A channel without connection_id posts as the organization's oldest connected bot, so set it whenever more than one bot is connected. A test or delivery fails with "needs a connected integration" when the named connection was removed or is not a Telegram connection.

If the test fails, the reported HTTP status says why:

Status	Meaning	What to do
400	Telegram does not know the chat, or the topic does not exist	Check the chat ID and topic ID, and that the bot was added to the chat
401 or 404	The bot token is no longer valid	Replace the credential on the Telegram provider of the Connections tab
403	The bot was removed, blocked, or may not post there	Add the bot back, or grant it permission to post
429	Telegram is rate-limiting the bot	Wait; deliveries are retried after the delay Telegram asks for

Telegram allows a bot about 20 messages a minute in one group, so route noisy rules elsewhere or group them. Messages longer than Telegram's 4,096-character limit are shortened. When a group is upgraded to a supergroup Telegram gives it a new ID and deliveries start failing with status 400; update the channel with the new ID. Telegram delivery is one-way: acknowledging or resolving in Anectico is not reflected in the chat, and replies in the chat are not read.

Provider rate-limit responses can postpone retries according to Retry-After, bounded to 24 hours and never shorter than the normal backoff. Slack message previews are shortened to fit its section limit. Slack, PagerDuty and Telegram delivery do not follow redirects; configure the final destination. Custom notification bodies and email subjects are validated by rendering sample data and have a 1 MiB rendered output limit. Invalid field references and incompatible template operations encountered in that sample render are rejected at save. Subjects are plain text: {{.RuleName}} inserts the rule name, while {{.RuleNmae}} is invalid. If an email subject fails with actual alert data, the notification uses the default [SEVERITY] message subject. Clear the subject to use that default; omit it from an update to keep the existing subject.

Customize what a channel says

Each channel type (email, Slack, webhook and so on) renders through the built-in default template until your organization creates a custom template for that type. There is at most one custom template per channel type. From the CLI:

anectico channels templates effective slack      # the template Slack deliveries use (404: built-in default)
anectico channels templates get <template-id>    # includes the version an update must name
anectico channels templates update <template-id> --expected-version 3 --body '{"template":"..."}'

An update names the version you read. If someone changed the template since, it is refused and nothing changes. An MCP agent can do the same with get_effective_notification_template, list_notification_templates, get_notification_template, create_notification_template, update_notification_template and delete_notification_template. It can also discover channels with list_notification_channels and get_notification_channel. These reads show a channel's routing — email recipients, the Slack channel, and a webhook's method and header names. The entire webhook URL and every header value are hidden in all responses, including after creation or an update.

When editing a webhook, leave its URL blank to keep the stored destination, or enter a new URL to replace it. Leave an existing header value blank to keep it; remove the header row to delete that header. API updates may omit url and headers to retain them, or echo [REDACTED] for existing secrets. An explicit empty headers object removes all headers. New channels require a real URL and credential values. A metadata edit preserves the current credentials even when another administrator rotates them concurrently.

Secure webhook reconfiguration

Webhook URLs and every header value are encrypted at rest and withheld from reads, create replies, update replies, previews and activity records. The entire URL is hidden because credentials can appear anywhere in it. A missing encryption key or unavailable stored credential refuses saved channel tests and delivery, including retries and reports. Email and connected-provider channels remain usable. Keep secrets in the owner's approved private handoff; never put them in a report.

Existing development webhook credentials have been cleared and their channels disabled. Reads cannot recover them. Retaining an omitted, blank or redacted value on a cleared or undecryptable channel is refused. Ask the owner for a complete new URL and all desired header values through a private handoff. Supply an explicit headers object: {} removes every header. Do not include blank or redacted header values in a complete replacement. Replacing credentials preserves the disabled state.

Use get_notification_channel or anectico channels get <id> for the current version, then update_notification_channel through execute_internal_action, or anectico channels update <id> --expected-version <updated_at> --file <private-file>. Review the replacement preview and repeat identical inputs with confirm_token or --confirm-token only after approval. Re-read, then separately preview and approve is_enabled: true at the new version. A replacement combined with enabling a disabled channel is refused. A real test uses test_notification_channel through execute_external_action or anectico channels test <id> and requires its own approval. Keep the creation --idempotency-key stable for any create retry; an update instead uses the current version.

If the deployment encryption key changes, existing saved credentials become unavailable. Coordinate with the operator to restore the intended key or use the complete replacement procedure under the new valid key. Neither omission nor a redaction marker recovers old values. Reset pending deliveries are closed with webhook_configuration_reset; interrupted report submissions retain an unknown outcome. Re-enabling does not replay that closed work.

Only attach a channel to an alert rule after the test succeeds. When deleting a channel, update every rule that routes to it; those rules will otherwise stop delivering to that destination.

A failed test reports one of a fixed set of plain-language reasons — an invalid or incomplete configuration, a malformed or non-routable webhook URL, a missing connected integration, an unreachable destination, or a destination that answered and refused, in which case its own HTTP status is included. As with the sanitized provider errors in delivery history, these reasons never carry raw provider error text or any part of the stored channel configuration. See Alerts or integrations are not delivering for the full list and what each one points at.

What reaches a channel without a rule

Most deliveries come from an alert rule you attached the channel to. Two things reach every enabled channel in the organization without one:

• an incident opening or resolving;
• an agent review signal opening or clearing — an undeclared agent, a deployment whose configuration no longer matches the bill of materials that attests it, or a deployment with no registered configuration at all.

A review signal that is still standing is not re-announced while it stands; you get one message when it opens and one when it clears, and the two are paired so the second closes out the first. If you do not want these on a destination, disable that channel — they are not rule-routed, so removing a rule will not stop them.

Configure personal contact methods

In the Console, open Connections and notifications (/connections), choose the Notifications tab, and use the My contact methods card to add an email address or Slack DM destination. Those are the personal methods that deliver today; SMS and phone are coming soon and cannot be selected. Slack DM requires an active Slack connection. Contact methods belong to the signed-in member, while notification channels belong to the organization.

After adding a contact method, confirm it is available when building the relevant on-call and escalation workflow. To change one in place, keeping its id and history, use anectico oncall contact-methods update <method-id> with only the fields you are changing (--type, --value, --label, --position); the others keep their current values.

A contact method also carries a verification state, shown alongside it and set by Anectico itself. It records whether the address was confirmed to belong to you, so it is not something you, the CLI, the API or an agent can set: a value supplied on a create or an update is ignored, and an edit that changes the destination clears it. Read it; do not send it. If a responder has no personal method, on-call delivery can use that member's confirmed account email as a fallback without adding an editable contact-method row.

Slack alert and escalation messages include Acknowledge. Anectico accepts the click only after Slack signature and freshness verification and an explicit mapping from that Slack user to a current Anectico organization member. The first ACK wins across Slack, the CLI, MCP and the REST API; repeated clicks cannot change its actor, time, or note, and the canonical ACK stops the escalation.

The same explicit mapping is what lets the Acknowledge, Resolve, and Assign to me buttons on an incident's pinned Slack summary work: without it, clicking any of them gets you a private "link your Slack account" reply and changes nothing.

Only the person who installed the Slack app is mapped automatically. Map each other responder's Slack user to their Anectico account:

anectico connections mappings list <slack-connection-id>
anectico connections mappings set <slack-connection-id> --external-user-id U0123ABCD --member-id <user-id> --yes --confirm-token <token>
anectico connections mappings delete <mapping-id> --yes --confirm-token <token>

Setting a mapping for a Slack user who already has one moves them to the new member. Listing and changing mappings also needs permission to read your organization's members. An MCP agent uses list_identity_mappings, map_external_identity and unmap_external_identity. The two writes show a complete before and after preview and need its confirmation token. The native CLI uses the same preview: omit --confirm-token for that first request, then repeat the identical arguments with the returned token. The preview names the connections and member read permissions as well as connections write permission.

Troubleshoot delivery

1. Test the saved notification channel directly.
2. Confirm its connection is active and the destination still exists.
3. Confirm the alert rule is enabled and routes to that exact channel.
4. Check whether the alert actually entered the firing state.
5. For on-call paging, confirm the active schedule, escalation step, and responder contact method.
6. Ask your agent to read delivery history for the same project as the alert, with list_notification_deliveries (CLI: anectico deliveries list). Delivery records are project-scoped and show attempts, sanitized provider errors, and provider correlation IDs without exposing secrets.

For durable alert and incident deliveries, each send attempt is recorded before contacting the provider. An attempt can therefore have an unknown outcome after a crash, and a retry can produce a duplicate. The persisted attempt budget still applies across worker restarts; once exhausted, the delivery moves to dlq instead of sending again. Attempts are not a count of confirmed receipts. Silence and analytics-source holds do not consume send attempts.

Delivery history requires channels:read and a selected project. REST and CLI pages default to 50 records and reject limits above 50. REST, MCP and CLI delivery reads return operational metadata; rendered notification payloads are never returned through these customer receipts.

For metric-watch deliveries, payload_withheld: true additionally tells you that the original metric content could not be authorized with your current credential and retained evidence. The check requires alerts:rules:read, analytics:read, persons:read, insights:read, and the original saved insight's source permissions (for example, agents:content:read). Missing permissions, erased or expired evidence, removed correlation, or an unavailable source check can cause this flag. Status and attempts remain visible, and the flag does not mean delivery failed. A false flag does not make rendered content part of the customer receipt. Pausing a watch does not itself invalidate readable history. History reads never rerun a query to replace the original measurement.

For ordinary cohort alerts, payload_withheld checks the exact cohort generation recorded with the notification. In addition to channels:read, you need analytics:read and that generation's source permissions, such as persons:profile:read for property cohorts or agents:content:read for content-dependent behavioral cohorts. Missing permissions, erased or expired evidence, and an unavailable source check withhold content while preserving delivery status and attempts. The current cohort generation never replaces the original generation during a history read. These receipts still omit rendered notification payloads even when the flag is false.

For ordinary cohort notifications, background cleanup also removes the retained rendered body when the original generation is permanently pruned or its original content-erasure evidence has been invalidated. Delivery status and attempt history remain available. A pending notification then stops retrying. Cleanup runs in bounded passes, so physical removal can follow the earlier read and send refusal. Temporary permission loss, policy denial or an unavailable source check does not itself delete history. Once the body is removed, a retry cannot restore it.

For native metric-watch notifications, cleanup follows the original published analytics result. Its immutable expiry or a completed change to its original content-erasure revisions can remove the retained rendered body. The original result and snapshot remain the reference even after the result payload is pruned. Pausing the watch, changing its latest revision, losing permissions, or an unavailable check does not by itself delete the body. Missing or corrupt original lifecycle evidence also prevents deletion. Delivery receipts remain available, and unfinished retries stop after the body is removed. These notifications use the same bounded cleanup scheduling described above.

Never paste provider tokens or routing keys into support messages.

• Create alerts
• Handle incidents and on-call

Removing a stored connection

Deleting a connection permanently destroys its stored credential, refresh token, signing secret and setup metadata. Its identifier, provider, label, revoked status and audit times remain so earlier delivery records still name their source. Any pending reauthorization is cancelled. This removes Anectico's stored authority; it does not revoke a credential at the provider or delete earlier delivered tickets and notifications. Reconnecting requires a new connection and a new credential.

Agent confirmation for connections

create_connection, update_connection, delete_connection and request_oauth_handoff preview complete current and proposed configuration on the server. Jira webhook signing-secret rotation uses webhook_secret (20–1024 bytes); reads report has_webhook_secret without returning the value. Secrets are withheld; presence and replacement are explicit. Metadata is returned marked as untrusted text. Positive expected versions are enforced for every changed field; rotating either credential requires one. Revocation also requires connections:delete. Preview and apply require connections:read as well as their write or deletion scope, including retries of a creation.

The native commands anectico connections create --file connection.json --idempotency-key <key>, anectico connections update <id> --file change.json, anectico connections delete <id> --yes, and anectico connections oauth handoff slack --idempotency-key <key> preview first. After approval repeat identical arguments with --confirm-token <token>. Keep the creation key for retries: it returns the first result. Confirming a handoff records consent intent; the person must open its private authorization link. Deleting a connection does not revoke authorization at the external provider. Remove that authorization there when appropriate.

Structured OAuth setup uses anectico connections oauth handoff jira --metadata-json '{"jira_custom_fields":{"priority":{"id":"1"}}}' --idempotency-key <key>. You may combine it with --metadata jira_project=ENG when their keys differ. MCP accepts the same nested metadata object. Repeat identical arguments with --confirm-token <token> only after reviewing the server preview.

For a connection that needs consent again, request a handoff with --reauthorize <connection-id> (MCP connection_id). Its target version is bound to that handoff.

REST connection creation returns the connection and preview and replay flags together:

{"connection": {}, "preview_only": true, "existing": false}

The preview flag means the proposed connection has not been stored; the existing flag means the retry key already identifies the original result. The Console keeps the key when retrying an unchanged credential form and replaces it when the form is edited. The effective-template read agrees across MCP and CLI: built_in_default: true explicitly identifies the built-in fallback when no custom template exists. A channel test sends a real diagnostic message through the external action door after preview and confirmation. It creates an action receipt with the diagnostic result, and no notification delivery record; sender acceptance is not human acknowledgement.

Delivery detail includes an attempt-history page, oldest first, default 20 and maximum 50. MCP accepts limit and cursor; CLI accepts --limit and --cursor. Follow the returned continuation token to read the rest. Recorded attempts include their number, start, completion when known, duration when known, result and error classification and retry time. history_state: partial_history identifies unrecorded older attempts. An unfinished unknown attempt may have reached its provider. Rendered messages and private destinations remain explicitly withheld.

Pause and resume require the monitor’s current configuration revision. Verify or remove a custom domain using its current updated_at as expected_version / --expected-version. Signing-secret rotation requires the incoming source’s current positive version as expected_version / --expected-version. Checklist changes require the incident’s incident_version from ownership detail as expected_revision / --revision. A stale version needs a new read and preview.

Channel and custom-template lists are pages. Use MCP limit and cursor, or CLI --limit and --cursor, to continue with the returned token. The default page is 100 entries and the maximum is 500. Keep the filters unchanged between pages. A page count describes only that page.

Connection and Slack mapping lists are pages. MCP accepts limit and cursor; CLI uses --limit and --cursor. Every page states its returned count and whether more exist. Pass the returned cursor unchanged with the same provider or connection selection. A partial mapping page cannot establish that a Slack user is unmapped.