chore: Run pnpm format:fix.

docs/automation/auth-monitoring.md

@@ -4,6 +4,7 @@ read_when:
   - Setting up auth expiry monitoring or alerts
   - Automating Claude Code / Codex OAuth refresh checks
 ---
+
 # Auth monitoring
 
 OpenClaw exposes OAuth expiry health via `openclaw models status`. Use that for
@@ -16,6 +17,7 @@ openclaw models status --check
 ```
 
 Exit codes:
+
 - `0`: OK
 - `1`: expired or missing credentials
 - `2`: expiring soon (within 24h)

docs/automation/cron-jobs.md

@@ -5,6 +5,7 @@ read_when:
   - Wiring automation that should run with or alongside heartbeats
   - Deciding between heartbeat and cron for scheduled tasks
 ---
+
 # Cron jobs (Gateway scheduler)
 
 > **Cron vs Heartbeat?** See [Cron vs Heartbeat](/automation/cron-vs-heartbeat) for guidance on when to use each.
@@ -12,10 +13,11 @@ read_when:
 Cron is the Gateway’s built-in scheduler. It persists jobs, wakes the agent at
 the right time, and can optionally deliver output back to a chat.
 
-If you want *“run this every morning”* or *“poke the agent in 20 minutes”*,
+If you want _“run this every morning”_ or _“poke the agent in 20 minutes”_,
 cron is the mechanism.
 
 ## TL;DR
+
 - Cron runs **inside the Gateway** (not inside the model).
 - Jobs persist under `~/.openclaw/cron/` so restarts don’t lose schedules.
 - Two execution styles:
@@ -24,18 +26,19 @@ cron is the mechanism.
 - Wakeups are first-class: a job can request “wake now” vs “next heartbeat”.
 
 ## Beginner-friendly overview
+
 Think of a cron job as: **when** to run + **what** to do.
 
-1) **Choose a schedule**
+1. **Choose a schedule**
    - One-shot reminder → `schedule.kind = "at"` (CLI: `--at`)
    - Repeating job → `schedule.kind = "every"` or `schedule.kind = "cron"`
    - If your ISO timestamp omits a timezone, it is treated as **UTC**.
 
-2) **Choose where it runs**
+2. **Choose where it runs**
    - `sessionTarget: "main"` → run during the next heartbeat with main context.
    - `sessionTarget: "isolated"` → run a dedicated agent turn in `cron:<jobId>`.
 
-3) **Choose the payload**
+3. **Choose the payload**
    - Main session → `payload.kind = "systemEvent"`
    - Isolated session → `payload.kind = "agentTurn"`
 
@@ -44,7 +47,9 @@ Optional: `deleteAfterRun: true` removes successful one-shot jobs from the store
 ## Concepts
 
 ### Jobs
+
 A cron job is a stored record with:
+
 - a **schedule** (when it should run),
 - a **payload** (what it should do),
 - optional **delivery** (where output should be sent).
@@ -56,7 +61,9 @@ In agent tool calls, `jobId` is canonical; legacy `id` is accepted for compatibi
 Jobs can optionally auto-delete after a successful one-shot run via `deleteAfterRun: true`.
 
 ### Schedules
+
 Cron supports three schedule kinds:
+
 - `at`: one-shot timestamp (ms since epoch). Gateway accepts ISO 8601 and coerces to UTC.
 - `every`: fixed interval (ms).
 - `cron`: 5-field cron expression with optional IANA timezone.
@@ -67,6 +74,7 @@ local timezone is used.
 ### Main vs isolated execution
 
 #### Main session jobs (system events)
+
 Main jobs enqueue a system event and optionally wake the heartbeat runner.
 They must use `payload.kind = "systemEvent"`.
 
@@ -77,9 +85,11 @@ This is the best fit when you want the normal heartbeat prompt + main-session co
 See [Heartbeat](/gateway/heartbeat).
 
 #### Isolated jobs (dedicated cron sessions)
+
 Isolated jobs run a dedicated agent turn in session `cron:<jobId>`.
 
 Key behaviors:
+
 - Prompt is prefixed with `[cron:<jobId> <job name>]` for traceability.
 - Each run starts a **fresh session id** (no prior conversation carry-over).
 - A summary is posted to the main session (prefix `Cron`, configurable).
@@ -90,11 +100,14 @@ Use isolated jobs for noisy, frequent, or "background chores" that shouldn't spa
 your main chat history.
 
 ### Payload shapes (what runs)
+
 Two payload kinds are supported:
+
 - `systemEvent`: main-session only, routed through the heartbeat prompt.
 - `agentTurn`: isolated-session only, runs a dedicated agent turn.
 
 Common `agentTurn` fields:
+
 - `message`: required text prompt.
 - `model` / `thinking`: optional overrides (see below).
 - `timeoutSeconds`: optional timeout override.
@@ -104,12 +117,15 @@ Common `agentTurn` fields:
 - `bestEffortDeliver`: avoid failing the job if delivery fails.
 
 Isolation options (only for `session=isolated`):
+
 - `postToMainPrefix` (CLI: `--post-prefix`): prefix for the system event in main.
 - `postToMainMode`: `summary` (default) or `full`.
 - `postToMainMaxChars`: max chars when `postToMainMode=full` (default 8000).
 
 ### Model and thinking overrides
+
 Isolated jobs (`agentTurn`) can override the model and thinking level:
+
 - `model`: Provider/model string (e.g., `anthropic/claude-sonnet-4-20250514`) or alias (e.g., `opus`)
 - `thinking`: Thinking level (`off`, `minimal`, `low`, `medium`, `high`, `xhigh`; GPT-5.2 + Codex models only)
 
@@ -118,12 +134,15 @@ session model. We recommend model overrides only for isolated jobs to avoid
 unexpected context shifts.
 
 Resolution priority:
+
 1. Job payload override (highest)
 2. Hook-specific defaults (e.g., `hooks.gmail.model`)
 3. Agent config default
 
 ### Delivery (channel + target)
+
 Isolated jobs can deliver output to a channel. The job payload can specify:
+
 - `channel`: `whatsapp` / `telegram` / `discord` / `slack` / `mattermost` (plugin) / `signal` / `imessage` / `last`
 - `to`: channel-specific recipient target
 
@@ -131,15 +150,18 @@ If `channel` or `to` is omitted, cron can fall back to the main session’s “l
 (the last place the agent replied).
 
 Delivery notes:
+
 - If `to` is set, cron auto-delivers the agent’s final output even if `deliver` is omitted.
 - Use `deliver: true` when you want last-route delivery without an explicit `to`.
 - Use `deliver: false` to keep output internal even if a `to` is present.
 
 Target format reminders:
+
 - Slack/Discord/Mattermost (plugin) targets should use explicit prefixes (e.g. `channel:<id>`, `user:<id>`) to avoid ambiguity.
 - Telegram topics should use the `:topic:` form (see below).
 
 #### Telegram delivery targets (topics / forum threads)
+
 Telegram supports forum topics via `message_thread_id`. For cron delivery, you can encode
 the topic/thread into the `to` field:
 
@@ -148,9 +170,11 @@ the topic/thread into the `to` field:
 - `-1001234567890:123` (shorthand: numeric suffix)
 
 Prefixed targets like `telegram:...` / `telegram:group:...` are also accepted:
+
 - `telegram:group:-1001234567890:topic:123`
 
 ## Storage & history
+
 - Job store: `~/.openclaw/cron/jobs.json` (Gateway-managed JSON).
 - Run history: `~/.openclaw/cron/runs/<jobId>.jsonl` (JSONL, auto-pruned).
 - Override store path: `cron.store` in config.
@@ -162,18 +186,20 @@ Prefixed targets like `telegram:...` / `telegram:group:...` are also accepted:
   cron: {
     enabled: true, // default true
     store: "~/.openclaw/cron/jobs.json",
-    maxConcurrentRuns: 1 // default 1
-  }
+    maxConcurrentRuns: 1, // default 1
+  },
 }
 ```
 
 Disable cron entirely:
+
 - `cron.enabled: false` (config)
 - `OPENCLAW_SKIP_CRON=1` (env)
 
 ## CLI quickstart
 
 One-shot reminder (UTC ISO, auto-delete after success):
+
 ```bash
 openclaw cron add \
   --name "Send reminder" \
@@ -185,6 +211,7 @@ openclaw cron add \
 ```
 
 One-shot reminder (main session, wake immediately):
+
 ```bash
 openclaw cron add \
   --name "Calendar check" \
@@ -195,6 +222,7 @@ openclaw cron add \
 ```
 
 Recurring isolated job (deliver to WhatsApp):
+
 ```bash
 openclaw cron add \
   --name "Morning status" \
@@ -208,6 +236,7 @@ openclaw cron add \
 ```
 
 Recurring isolated job (deliver to a Telegram topic):
+
 ```bash
 openclaw cron add \
   --name "Nightly summary (topic)" \
@@ -221,7 +250,8 @@ openclaw cron add \
 ```
 
 Isolated job with model and thinking override:
-```bash
+
+````bash
 openclaw cron add \
   --name "Deep analysis" \
   --cron "0 6 * * 1" \
@@ -242,15 +272,17 @@ openclaw cron add --name "Ops sweep" --cron "0 6 * * *" --session isolated --mes
 # Switch or clear the agent on an existing job
 openclaw cron edit <jobId> --agent ops
 openclaw cron edit <jobId> --clear-agent
-```
-```
+````
+
+````
 
 Manual run (debug):
 ```bash
 openclaw cron run <jobId> --force
-```
+````
 
 Edit an existing job (patch fields):
+
 ```bash
 openclaw cron edit <jobId> \
   --message "Updated prompt" \
@@ -259,28 +291,33 @@ openclaw cron edit <jobId> \
 ```
 
 Run history:
+
 ```bash
 openclaw cron runs --id <jobId> --limit 50
 ```
 
 Immediate system event without creating a job:
+
 ```bash
 openclaw system event --mode now --text "Next heartbeat: check battery."
 ```
 
 ## Gateway API surface
+
 - `cron.list`, `cron.status`, `cron.add`, `cron.update`, `cron.remove`
 - `cron.run` (force or due), `cron.runs`
-For immediate system events without a job, use [`openclaw system event`](/cli/system).
+  For immediate system events without a job, use [`openclaw system event`](/cli/system).
 
 ## Troubleshooting
 
 ### “Nothing runs”
+
 - Check cron is enabled: `cron.enabled` and `OPENCLAW_SKIP_CRON`.
 - Check the Gateway is running continuously (cron runs inside the Gateway process).
 - For `cron` schedules: confirm timezone (`--tz`) vs the host timezone.
 
 ### Telegram delivers to the wrong place
+
 - For forum topics, use `-100…:topic:<id>` so it’s explicit and unambiguous.
 - If you see `telegram:...` prefixes in logs or stored “last route” targets, that’s normal;
   cron delivery accepts them and still parses topic IDs correctly.

docs/automation/cron-vs-heartbeat.md

@@ -5,20 +5,21 @@ read_when:
   - Setting up background monitoring or notifications
   - Optimizing token usage for periodic checks
 ---
+
 # Cron vs Heartbeat: When to Use Each
 
 Both heartbeats and cron jobs let you run tasks on a schedule. This guide helps you choose the right mechanism for your use case.
 
 ## Quick Decision Guide
 
-| Use Case | Recommended | Why |
-|----------|-------------|-----|
-| Check inbox every 30 min | Heartbeat | Batches with other checks, context-aware |
-| Send daily report at 9am sharp | Cron (isolated) | Exact timing needed |
-| Monitor calendar for upcoming events | Heartbeat | Natural fit for periodic awareness |
-| Run weekly deep analysis | Cron (isolated) | Standalone task, can use different model |
-| Remind me in 20 minutes | Cron (main, `--at`) | One-shot with precise timing |
-| Background project health check | Heartbeat | Piggybacks on existing cycle |
+| Use Case                             | Recommended         | Why                                      |
+| ------------------------------------ | ------------------- | ---------------------------------------- |
+| Check inbox every 30 min             | Heartbeat           | Batches with other checks, context-aware |
+| Send daily report at 9am sharp       | Cron (isolated)     | Exact timing needed                      |
+| Monitor calendar for upcoming events | Heartbeat           | Natural fit for periodic awareness       |
+| Run weekly deep analysis             | Cron (isolated)     | Standalone task, can use different model |
+| Remind me in 20 minutes              | Cron (main, `--at`) | One-shot with precise timing             |
+| Background project health check      | Heartbeat           | Piggybacks on existing cycle             |
 
 ## Heartbeat: Periodic Awareness
 
@@ -59,12 +60,12 @@ The agent reads this on each heartbeat and handles all items in one turn.
   agents: {
     defaults: {
       heartbeat: {
-        every: "30m",        // interval
-        target: "last",      // where to deliver alerts
-        activeHours: { start: "08:00", end: "22:00" }  // optional
-      }
-    }
-  }
+        every: "30m", // interval
+        target: "last", // where to deliver alerts
+        activeHours: { start: "08:00", end: "22:00" }, // optional
+      },
+    },
+  },
 }
 ```
 
@@ -157,8 +158,10 @@ The most efficient setup uses **both**:
 ### Example: Efficient automation setup
 
 **HEARTBEAT.md** (checked every 30 min):
+
 ```md
 # Heartbeat checklist
+
 - Scan inbox for urgent emails
 - Check calendar for events in next 2h
 - Review any pending tasks
@@ -166,6 +169,7 @@ The most efficient setup uses **both**:
 ```
 
 **Cron jobs** (precise timing):
+
 ```bash
 # Daily morning briefing at 7am
 openclaw cron add --name "Morning brief" --cron "0 7 * * *" --session isolated --message "..." --deliver
@@ -177,7 +181,6 @@ openclaw cron add --name "Weekly review" --cron "0 9 * * 1" --session isolated -
 openclaw cron add --name "Call back" --at "2h" --session main --system-event "Call back the client" --wake now
 ```
 
-
 ## Lobster: Deterministic workflows with approvals
 
 Lobster is the workflow runtime for **multi-step tool pipelines** that need deterministic execution and explicit approvals.
@@ -191,8 +194,8 @@ Use it when the task is more than a single agent turn, and you want a resumable
 
 ### How it pairs with heartbeat and cron
 
-- **Heartbeat/cron** decide *when* a run happens.
-- **Lobster** defines *what steps* happen once the run starts.
+- **Heartbeat/cron** decide _when_ a run happens.
+- **Lobster** defines _what steps_ happen once the run starts.
 
 For scheduled workflows, use cron or heartbeat to trigger an agent turn that calls Lobster.
 For ad-hoc workflows, call Lobster directly.
@@ -210,17 +213,18 @@ See [Lobster](/tools/lobster) for full usage and examples.
 
 Both heartbeat and cron can interact with the main session, but differently:
 
-| | Heartbeat | Cron (main) | Cron (isolated) |
-|---|---|---|---|
-| Session | Main | Main (via system event) | `cron:<jobId>` |
-| History | Shared | Shared | Fresh each run |
-| Context | Full | Full | None (starts clean) |
-| Model | Main session model | Main session model | Can override |
-| Output | Delivered if not `HEARTBEAT_OK` | Heartbeat prompt + event | Summary posted to main |
+|         | Heartbeat                       | Cron (main)              | Cron (isolated)        |
+| ------- | ------------------------------- | ------------------------ | ---------------------- |
+| Session | Main                            | Main (via system event)  | `cron:<jobId>`         |
+| History | Shared                          | Shared                   | Fresh each run         |
+| Context | Full                            | Full                     | None (starts clean)    |
+| Model   | Main session model              | Main session model       | Can override           |
+| Output  | Delivered if not `HEARTBEAT_OK` | Heartbeat prompt + event | Summary posted to main |
 
 ### When to use main session cron
 
 Use `--session main` with `--system-event` when you want:
+
 - The reminder/event to appear in main session context
 - The agent to handle it during the next heartbeat with full context
 - No separate isolated run
@@ -237,6 +241,7 @@ openclaw cron add \
 ### When to use isolated cron
 
 Use `--session isolated` when you want:
+
 - A clean slate without prior context
 - Different model or thinking settings
 - Output delivered directly to a channel (summary still posts to main by default)
@@ -255,13 +260,14 @@ openclaw cron add \
 
 ## Cost Considerations
 
-| Mechanism | Cost Profile |
-|-----------|--------------|
-| Heartbeat | One turn every N minutes; scales with HEARTBEAT.md size |
-| Cron (main) | Adds event to next heartbeat (no isolated turn) |
-| Cron (isolated) | Full agent turn per job; can use cheaper model |
+| Mechanism       | Cost Profile                                            |
+| --------------- | ------------------------------------------------------- |
+| Heartbeat       | One turn every N minutes; scales with HEARTBEAT.md size |
+| Cron (main)     | Adds event to next heartbeat (no isolated turn)         |
+| Cron (isolated) | Full agent turn per job; can use cheaper model          |
 
 **Tips**:
+
 - Keep `HEARTBEAT.md` small to minimize token overhead.
 - Batch similar checks into heartbeat instead of multiple cron jobs.
 - Use `target: "none"` on heartbeat if you only want internal processing.

docs/automation/gmail-pubsub.md

@@ -26,8 +26,8 @@ Example hook config (enable Gmail preset mapping):
     enabled: true,
     token: "OPENCLAW_HOOK_TOKEN",
     path: "/hooks",
-    presets: ["gmail"]
-  }
+    presets: ["gmail"],
+  },
 }
 ```
 
@@ -47,15 +47,14 @@ that sets `deliver` + optional `channel`/`to`:
         wakeMode: "now",
         name: "Gmail",
         sessionKey: "hook:gmail:{{messages[0].id}}",
-        messageTemplate:
-          "New email from {{messages[0].from}}\nSubject: {{messages[0].subject}}\n{{messages[0].snippet}}\n{{messages[0].body}}",
+        messageTemplate: "New email from {{messages[0].from}}\nSubject: {{messages[0].subject}}\n{{messages[0].snippet}}\n{{messages[0].body}}",
         model: "openai/gpt-5.2-mini",
         deliver: true,
-        channel: "last"
+        channel: "last",
         // to: "+15551234567"
-      }
-    ]
-  }
+      },
+    ],
+  },
 }
 ```
 
@@ -73,13 +72,14 @@ To set a default model and thinking level specifically for Gmail hooks, add
   hooks: {
     gmail: {
       model: "openrouter/meta-llama/llama-3.3-70b-instruct:free",
-      thinking: "off"
-    }
-  }
+      thinking: "off",
+    },
+  },
 }
 ```
 
 Notes:
+
 - Per-hook `model`/`thinking` in the mapping still overrides these defaults.
 - Fallback order: `hooks.gmail.model` → `agents.defaults.model.fallbacks` → primary (auth/rate-limit/timeouts).
 - If `agents.defaults.models` is set, the Gmail model must be in the allowlist.
@@ -99,6 +99,7 @@ openclaw webhooks gmail setup \
 ```
 
 Defaults:
+
 - Uses Tailscale Funnel for the public push endpoint.
 - Writes `hooks.gmail` config for `openclaw webhooks gmail run`.
 - Enables the Gmail hook preset (`hooks.presets: ["gmail"]`).
@@ -117,6 +118,7 @@ Platform note: on macOS the wizard installs `gcloud`, `gogcli`, and `tailscale`
 via Homebrew; on Linux install them manually first.
 
 Gateway auto-start (recommended):
+
 - When `hooks.enabled=true` and `hooks.gmail.account` is set, the Gateway starts
   `gog gmail watch serve` on boot and auto-renews the watch.
 - Set `OPENCLAW_SKIP_GMAIL_WATCHER=1` to opt out (useful if you run the daemon yourself).
@@ -131,7 +133,7 @@ openclaw webhooks gmail run
 
 ## One-time setup
 
-1) Select the GCP project **that owns the OAuth client** used by `gog`.
+1. Select the GCP project **that owns the OAuth client** used by `gog`.
 
 ```bash
 gcloud auth login
@@ -140,19 +142,19 @@ gcloud config set project <project-id>
 
 Note: Gmail watch requires the Pub/Sub topic to live in the same project as the OAuth client.
 
-2) Enable APIs:
+2. Enable APIs:
 
 ```bash
 gcloud services enable gmail.googleapis.com pubsub.googleapis.com
 ```
 
-3) Create a topic:
+3. Create a topic:
 
 ```bash
 gcloud pubsub topics create gog-gmail-watch
 ```
 
-4) Allow Gmail push to publish:
+4. Allow Gmail push to publish:
 
 ```bash
 gcloud pubsub topics add-iam-policy-binding gog-gmail-watch \
@@ -189,6 +191,7 @@ gog gmail watch serve \
 ```
 
 Notes:
+
 - `--token` protects the push endpoint (`x-gog-token` or `?token=`).
 - `--hook-url` points to OpenClaw `/hooks/gmail` (mapped; isolated run + summary to main).
 - `--include-body` and `--max-bytes` control the body snippet sent to OpenClaw.

docs/automation/poll.md

@@ -4,10 +4,11 @@ read_when:
   - Adding or modifying poll support
   - Debugging poll sends from the CLI or gateway
 ---
+
 # Polls
 
-
 ## Supported channels
+
 - WhatsApp (web channel)
 - Discord
 - MS Teams (Adaptive Cards)
@@ -33,6 +34,7 @@ openclaw message poll --channel msteams --target conversation:19:abc@thread.tacv
 ```
 
 Options:
+
 - `--channel`: `whatsapp` (default), `discord`, or `msteams`
 - `--poll-multi`: allow selecting multiple options
 - `--poll-duration-hours`: Discord-only (defaults to 24 when omitted)
@@ -42,6 +44,7 @@ Options:
 Method: `poll`
 
 Params:
+
 - `to` (string, required)
 - `question` (string, required)
 - `options` (string[], required)
@@ -51,11 +54,13 @@ Params:
 - `idempotencyKey` (string, required)
 
 ## Channel differences
+
 - WhatsApp: 2-12 options, `maxSelections` must be within option count, ignores `durationHours`.
 - Discord: 2-10 options, `durationHours` clamped to 1-768 hours (default 24). `maxSelections > 1` enables multi-select; Discord does not support a strict selection count.
 - MS Teams: Adaptive Card polls (OpenClaw-managed). No native poll API; `durationHours` is ignored.
 
 ## Agent tool (Message)
+
 Use the `message` tool with `poll` action (`to`, `pollQuestion`, `pollOption`, optional `pollMulti`, `pollDurationHours`, `channel`).
 
 Note: Discord has no “pick exactly N” mode; `pollMulti` maps to multi-select.

docs/automation/webhook.md

@@ -16,18 +16,20 @@ Gateway can expose a small HTTP webhook endpoint for external triggers.
   hooks: {
     enabled: true,
     token: "shared-secret",
-    path: "/hooks"
-  }
+    path: "/hooks",
+  },
 }
 ```
 
 Notes:
+
 - `hooks.token` is required when `hooks.enabled=true`.
 - `hooks.path` defaults to `/hooks`.
 
 ## Auth
 
 Every request must include the hook token. Prefer headers:
+
 - `Authorization: Bearer <token>` (recommended)
 - `x-openclaw-token: <token>`
 - `?token=<token>` (deprecated; logs a warning and will be removed in a future major release)
@@ -37,6 +39,7 @@ Every request must include the hook token. Prefer headers:
 ### `POST /hooks/wake`
 
 Payload:
+
 ```json
 { "text": "System line", "mode": "now" }
 ```
@@ -45,12 +48,14 @@ Payload:
 - `mode` optional (`now` | `next-heartbeat`): Whether to trigger an immediate heartbeat (default `now`) or wait for the next periodic check.
 
 Effect:
+
 - Enqueues a system event for the **main** session
 - If `mode=now`, triggers an immediate heartbeat
 
 ### `POST /hooks/agent`
 
 Payload:
+
 ```json
 {
   "message": "Run this",
@@ -78,6 +83,7 @@ Payload:
 - `timeoutSeconds` optional (number): Maximum duration for the agent run in seconds.
 
 Effect:
+
 - Runs an **isolated** agent turn (own session key)
 - Always posts a summary into the **main** session
 - If `wakeMode=now`, triggers an immediate heartbeat
@@ -89,6 +95,7 @@ turn arbitrary payloads into `wake` or `agent` actions, with optional templates
 code transforms.
 
 Mapping options (summary):
+
 - `hooks.presets: ["gmail"]` enables the built-in Gmail mapping.
 - `hooks.mappings` lets you define `match`, `action`, and templates in config.
 - `hooks.transformsDir` + `transform.module` loads a JS/TS module for custom logic.
@@ -99,7 +106,7 @@ Mapping options (summary):
 - `allowUnsafeExternalContent: true` disables the external content safety wrapper for that hook
   (dangerous; only for trusted internal sources).
 - `openclaw webhooks gmail setup` writes `hooks.gmail` config for `openclaw webhooks gmail run`.
-See [Gmail Pub/Sub](/automation/gmail-pubsub) for the full Gmail watch flow.
+  See [Gmail Pub/Sub](/automation/gmail-pubsub) for the full Gmail watch flow.
 
 ## Responses