Disable, revoke, and offboard a channel

Verifiedon 2026-07-302026.7.1

Deleting a config file is not offboarding

A messaging integration is a distributed path. It may include provider credentials, webhook registrations, Gateway or adapter configuration, queued retries, permission grants, local state, audit records, and people who still believe the channel is active. Removing one local file can leave every other part alive. Offboarding is complete only when inbound acceptance, outbound delivery, provider authority, and residual retention have each been checked.

Use the current OpenClaw documentation index and official release history for the exact disable, configuration, and credential controls in the version you operate. This course boundary is OpenClaw 2026.7.1, revision 2d2ddc43d0dcf71f31283d780f9fe9ff4cc04fe4, checked 2026-07-30. The runbook below is a provider-neutral tabletop; it is not proof that a real provider has been disabled.

The runbook sequence

Perform the steps in an order that closes the side-effect path early and preserves enough evidence to explain what happened:

1. Declare the change: record integration name, synthetic scope, owner, reason, start time, and safe interim state HOLD — no inbound or outbound action.
2. Freeze approvals: invalidate pending approvals and prevent new approval records from authorizing delivery during the change.
3. Stop inbound acceptance: disable the route or adapter so new provider events are rejected or quarantined. Record the control and observed result.
4. Stop outbound delivery: disable the delivery adapter and drain or quarantine retry queues. Do not delete an unresolved record; mark it for reconciliation.
5. Revoke or rotate credentials: use the provider’s current control to revoke the token, signing secret, service account, or connection. Rotation is not always revocation; verify the old credential is rejected.
6. Remove provider scope: delete webhook registrations, bot permissions, channel grants, subscriptions, or endpoints that can recreate the path. Capture a provider receipt without copying secrets.
7. Inspect residual state: identify local configuration, provider-side queued events, logs, caches, and retained message content. Retain only the approved audit record and document the retention owner.
8. Test the dead path: send a synthetic event and attempt a synthetic outbound action. Expected result is no acceptance and no delivery; record the denial or provider rejection.
9. Sign off: the change owner and verifier record timestamps, evidence IDs, limitations, and the condition required before reactivation.

If the provider’s documentation does not explain how to inspect queued events or verify credential revocation, the runbook is incomplete. Mark it as a limitation rather than claiming shutdown.

Worked example: two-ended disable proof

A test webhook is disabled locally at 12:00Z. A synthetic event sent at 12:02Z still receives an HTTP 200 because a provider-side webhook registration points at an old endpoint. This is not a successful shutdown. The owner disables the registration, revokes the test token, and repeats the event. The second attempt is rejected or quarantined, and a provider receipt is recorded. The local configuration file is then removed only after the dead-path evidence exists.

{
"integration": "synthetic-channel-v2",
"startedAt": "2026-07-30T12:00:00Z",
"inbound": "disabled-and-replayed",
"outbound": "disabled-and-queue-quarantined",
"credential": "revoked: secret:test-channel-v2",
"providerScope": "removed: synthetic-workspace/support-room",
"postDisableEvent": "rejected-or-quarantined",
"retentionOwner": "records-owner",
"verifiedBy": "integration-verifier"
}

The value after credential is a label, not a token. Never put the credential itself in a runbook or screenshot.

Lab: the disable-switch tabletop

Use the course capstone flow and pretend the integration must be stopped during an ambiguous provider incident. Work from a synthetic copy of the inventory and produce a timestamped runbook. At each step, answer what could still deliver after the step and what evidence proves it cannot.

Test these failure cases:

• Local disable only: provider continues to deliver to a stale endpoint. Expected: fail verification and remove the provider registration.
• Credential rotation only: old token remains valid. Expected: treat as not revoked and use the provider’s revoke control.
• Queue deletion only: an in-flight event is still accepted by the adapter. Expected: quarantine and reconcile, not erase.
• Outbound off, inbound on: a new inbound event still triggers work. Expected: stop inbound first and test both directions.
• Expired approval in queue: retry would reuse stale authority. Expected: invalidate approval and hold.

Rollback and reactivation boundary

Offboarding should be reversible in the sense that the decision record explains how to restore service, not in the sense that you keep old authority alive “just in case.” Keep the integration disabled. Reactivation requires a fresh inventory, identity allowlist, routing matrix, current provider documentation, new least-privilege credentials, and a new duplicate and approval test. Do not restore an old configuration snapshot with stale permissions or expired consent.

If a post-disable event is accepted, stop immediately and classify the residual path: old endpoint, cached process, queue, provider retry, or another adapter. Preserve the evidence, rotate affected credentials, and notify the owner. If real data appears in a test artifact, remove it from shared storage, follow the organization’s incident process, and do not conceal the mistake by rewriting timestamps.

The learner artifact is a redacted disable runbook with inbound stop, outbound stop, credential action, provider permission action, queue treatment, retention owner, test event, and verifier. The course capstone is non-pass if it cannot prove the path stopped.

Course capstone handoff

Combine this runbook with the inventory, identity sheet, routing matrix, duplicate-event result, unauthorised-recipient result, and human approval record. Your limitation must be concrete—for example, “provider queue inspection is unverified”—and must block publication to production until resolved. A course completion record is not a production approval.

Check your understanding

Source receipt

Primary source: OpenClaw documentation index. Version receipt: OpenClaw 2026.7.1, revision 2d2ddc43d0dcf71f31283d780f9fe9ff4cc04fe4, checked 2026-07-30. Official releases are the change authority. This provider-neutral exercise does not certify a real channel as disabled.