Channels, Messaging and Real-World Integrations

Operating boundary

This course does not teach “turn on every channel.” It teaches the opposite: start with one disposable path, know exactly who may send and receive, make delivery repeat-safe, and retain the option to stop.

The six lessons below are original, provider-neutral operating exercises rather than provider setup instructions. Publication covers the bounded routing, approval, replay, and offboarding methods. Provider-specific settings still require current official documentation and a disposable test environment.

Module 1 — Inventory before connection

Lesson 1.1: Classify the message path — map inbound data, sender identity, intended recipient, action class, storage, and retention before credentials are introduced. Lab: complete an integration inventory for one test workflow. Check: identify the one destination that must never receive an unapproved message.

Learner artifact: Draw a left-to-right path: sender → provider → channel adapter → policy gate → OpenClaw work → approval gate → delivery adapter → recipient. Put a red trust-boundary line around each third-party provider and label each arrow with data class and identity proof. Include an explicit drop path.

Module 2 — Identity, scope, and consent

Lesson 2.1: Bind identities, not display names — model Telegram, WhatsApp, Discord, and webhook actors as stable provider identities; treat display names and free-text headers as presentation, not authority. Lab: make an allowlist worksheet that has a stable ID, purpose, allowed operation, expiry, owner, and revocation method for every actor. Check: reject a correctly named but unallowlisted sender.

Provider research receipt checklist:

Surface	Primary evidence to capture before publication	What the reviewer must prove
Telegram	Official Bot API identity, privacy, and update-delivery documentation	Bot scope and test-chat identity handling
WhatsApp	Meta Cloud API webhook, access-token, and template/recipient documentation	Business account ownership, consent, and test-number boundary
Discord	Discord developer documentation for gateway intents, application permissions, and interaction/webhook verification	Minimum intents and server/channel allowlisting
Generic webhook	Provider signing, retry, and event-ID documentation	Signature verification, replay window, and event identity

Module 3 — Routing and recipient safety

Lesson 3.1: Write a routing rule a reviewer can audit — turn “send support messages to the team” into predicates over source, sender, classification, destination, action, and approval state. Lab: build the routing/access-control matrix in the lesson. Check: choose drop, hold for approval, or deliver for five cases.

Learner artifact: Capture a redacted routing matrix with test-only identities, an explicit default-deny row, a highlighted approval-required row, and a visible change owner. Never include tokens, personal phone numbers, real chat IDs, or customer text.

Module 4 — Delivery semantics, webhooks, and debugging

Lesson 4.1: Make delivery safe to repeat — distinguish accepted, queued, attempted, acknowledged, and confirmed delivery. Use provider event IDs or an owned idempotency key; never infer success from a request leaving your process. Lab: replay one event twice and show one durable decision record with no second side effect. Check: name the evidence needed to distinguish a retry from a new message.

Debugging card: Trace in this order: provider event ID → verified sender/endpoint → route decision → idempotency record → approval decision → outbound provider receipt. Stop when an identity or recipient cannot be proved. Do not “retry until it works.”

Module 5 — Human control and escalation

Lesson 5.1: Put the human gate where harm becomes possible — draft may be automated; delivery to an external recipient is a separate, logged decision. Lab: run a support-triage case through classification, draft, approval, delivery, and escalation. Check: write an escalation message that states uncertainty, owner, and next decision time without exposing sensitive content.

Learner artifact: Draw a swimlane diagram with Customer, Channel, OpenClaw, Approver, and Operator. Show that the draft crosses into the Approver lane before an outbound delivery action. Add a timeout that ends in “hold,” not “send.”

Module 6 — Audit, disable, and offboard

Lesson 6.1: End the connection deliberately — disable inbound acceptance, revoke or rotate credentials, remove provider permissions, preserve only the approved audit record, test the dead path, and record an owner for any residual retention. Lab: execute the disable-switch tabletop. Check: explain why deleting a local configuration file is not proof that a provider can no longer deliver.

Learner artifact: Capture a redacted disable runbook with timestamps for inbound stop, credential revocation, permission removal, retry-queue drain, and verification attempt. Use a synthetic workspace.

Course skill check

A learner passes the local checkpoint only when they can correctly decide the route for all required scenarios and complete the capstone evidence pack. This is a learning record, not a certificate.

1. A message has a recognised display name but an unallowlisted stable sender ID. Correct action: drop and log the policy reason. Display names are not an identity proof.
2. A provider retries an event after a timeout, with the same event ID. Correct action: look up the idempotency decision before any delivery; the response depends on the durable record, not on memory.
3. A draft response includes an irreversible external action. Correct action: hold for a named human approval; a successful draft is not delivery authority.

Capstone — bounded support triage

Build a test-only flow that receives a synthetic support message, classifies it, creates a draft, requires named human approval before external delivery, and records the decision. Your evidence pack includes:

• a routing/access-control matrix with default deny;
• a redacted identity and consent record;
• a duplicate-event result and unauthorised-recipient result;
• an approval and escalation record;
• a disable/offboarding runbook; and
• one limitation you would resolve before production use.

Rubric: scope and least privilege 30%; duplicate/misroute and failure handling 25%; human control 25%; auditability and offboarding 20%. A missing approval boundary, unbounded destination, or untested disable path is a non-pass.

Video and media decision

The curriculum ledger identifies VfmG9Q69p1o as a Discord case-study candidate only. It is deliberately not embedded here because it has not passed the required viewing, availability, technical-claim, rights, and privacy checks. Every lesson is complete without video.

Freshness and changelog seed

Freshness owner: academy-editorial. SLA: standard (60 days). Re-review immediately when OpenClaw channel documentation, provider webhook/signing semantics, permissions, or supported versions change. The course does not assert provider-specific runtime compatibility.