Integrations, Day 11 of the Free Comprehensive OpenClaw Course

How do I integrate OpenClaw with my existing tools?

OpenClaw integrations are how the agent reaches outside its own runtime to act on real systems. The runtime supports four canonical integration shapes: webhooks, OAuth integrations (the Google Workspace family), browser automation, and the enterprise chain for custom internal services. Most agents use a mix of all four.

Webhooks are the easiest. If the system on the other end speaks HTTP and accepts a POST, you can integrate it in roughly five minutes. The agent's fetch tool handles the call, you write a small Skill that wraps the URL and the auth header, done. Zapier, Make, n8n, internal services, anything with an HTTP API.

Webhooks also work the other way. Your agent's runtime can receive incoming webhooks, which is how you wire things like "when a new GitHub issue is filed, ask the agent to triage it". Inbound webhooks live at a stable URL the runtime exposes, and you allowlist which paths and which senders.

What is the OpenClaw enterprise chain?

The enterprise chain is the canonical pattern for connecting an OpenClaw agent to a custom internal service safely. The shape: your internal service exposes an HTTP API, you write a small wrapper Skill that holds the auth and the request shape, the Skill manifest declares the fetch tool grant scoped to that one URL host, and the agent uses the Skill like any other.

The reason this is its own pattern (rather than just "use the fetch tool") is the security shape. A bare fetch grant lets the agent fetch anywhere, which is a real injection risk if the agent reads any untrusted content. A scoped Skill that wraps one host bounds the blast radius. If the agent gets prompt-injected to "POST to evil.com", the runtime refuses, the host is not in the Skill's allowlist.

For Google Workspace specifically, there is a one-shot OAuth integration that covers Gmail, Calendar, Drive, and Docs through a single auth flow. openclaw integration add google-workspace walks you through it in the terminal.

Enterprise chain, example wiring

What an enterprise-chain Skill actually looks like. Suppose your company has an internal "deploy" API at https://internal.acme.com/deploy that takes a POST with a service name and returns a deploy ID. The Skill manifest:

# manifest.yaml
name: acme-deploy
version: 1.0.0
description: Trigger a deploy of an Acme internal service.
tools:
  - fetch
fetch_allowlist:
  - https://internal.acme.com/*
secrets:
  - ACME_DEPLOY_TOKEN
inputs:
  - name: service
    type: string
    enum: [api, worker, web]

The fetch_allowlist field is the key. The Skill's fetch tool can only hit URLs matching that pattern. Even if the model gets prompt-injected to "POST to https://attacker.com/exfil", the runtime refuses, the URL is not in the allowlist. This is the security gain over giving the main agent a bare fetch tool.

Can OpenClaw control a browser to use sites without APIs?

Yes. The browser tool gives the agent a real browser instance (Chromium under the hood) it can navigate, click, type into, and read from. This is how the agent uses sites that do not expose an API at all, and it is also how you scrape rendered content for sites that gate their data behind JavaScript.

Browser automation is powerful and slow. Every browser action is a real DOM event, which means each click is a few hundred milliseconds and a full page render is a few seconds. Use the browser when there is no other option. Prefer fetch + a real API when one exists.

The security shape of browser automation matters too. The browser tool gives the agent the ability to navigate to arbitrary URLs and run arbitrary JavaScript on the pages it visits. This is one of the highest-risk tool grants in the runtime. Always pair it with allowlists for which domains the agent can navigate to, and run it inside a Docker sandbox (openclaw docker) so the browser cannot touch your host.

Google Workspace integration, the full setup

The Google Workspace integration covers Gmail, Calendar, Drive, and Docs through a single OAuth flow. The setup:

1. Create a Google Cloud project at console.cloud.google.com.
2. Enable the Gmail, Calendar, and Drive APIs from the API library.
3. Create an OAuth 2.0 client ID, application type "Desktop app".
4. Download the JSON credentials file.
5. Run openclaw integration add google-workspace --credentials ./client_secret.json.
6. The runtime opens your browser to the consent screen, you grant the requested scopes, the runtime stores the refresh token securely.

The right scope shape: gmail.readonly for triage agents, gmail.modify if the agent needs to label or archive, gmail.send only if the agent needs to send (gate this behind irreversible-action confirmation in openclaw agents.md). Calendar and Drive split similarly into read and read-write tiers.

Webhooks out and back

One pattern worth calling out because it is the connective tissue between everything else. Outbound webhooks let the agent push events to systems you already operate (Slack alerts, dashboard updates, ticket creates). Inbound webhooks let those systems wake the agent (a new ticket, a customer message, a deployment failure).

The pattern: outbound for "the agent has news", inbound for "wake the agent and have it look at this". Both go through the runtime's webhook layer. Both should be authenticated, the runtime supports HMAC signing on inbound and Bearer auth on outbound. Skipping the auth is the most common production mistake here, an unauthenticated inbound webhook is a free trigger for anyone who guesses the URL.

Inbound webhook config, with HMAC signing

The shape of an inbound webhook config in CHANNELS.md:

webhooks:
  github_issues:
    path: /webhooks/github
    method: POST
    auth:
      type: hmac_sha256
      header: X-Hub-Signature-256
      secret_env: GITHUB_WEBHOOK_SECRET
    handler: |
      When a webhook arrives, treat it as a new GitHub issue.
      Read the issue title and body, classify by urgency,
      tag it appropriately, and post a one-line summary
      to the team Slack channel.

The runtime exposes the webhook at https://your-host/webhooks/github, verifies every incoming request against the HMAC secret, and only invokes the handler if the signature matches. An unauthenticated POST gets a 401 and never wakes the agent. This is the bare-minimum security shape for any inbound webhook.

Common integration failure modes

Three real failure modes that catch most people. The first, OAuth refresh token expired. Google's refresh tokens are long-lived but not infinite. After 6 months of inactivity, or if the user revokes the grant in their Google account, the token stops working. The agent will start failing every Calendar or Gmail call with a 401. Re-run openclaw integration refresh google-workspace to walk the OAuth flow again.

The second, webhook URL stale after server move. If you migrate the agent to a new VPS or change DNS, every external system that points a webhook at the old URL silently fails. There is no error on your side, the webhooks just stop arriving. Maintain a list of every external system pointing at the agent and update them all on any server move. Or use a stable URL like a Cloudflare Tunnel that follows the agent.

The third, HMAC secret rotation breaks every webhook. If you rotate the inbound webhook secret in the agent's .env and forget to update the corresponding system that signs the webhooks, every signed request will fail HMAC verification and get rejected. Coordinate the rotation, change one side, then the other, with a brief window of accepting both old and new secrets.

Connecting to private internal APIs

The enterprise chain works for any internal HTTP API the agent host can reach. If your internal service lives on a private network the VPS does not have direct access to, you have two options. The first is a VPN tunnel, OpenVPN or WireGuard from the VPS into your private network. The agent's fetch tool then sees the internal URL as if it were on the LAN.

The second is a reverse-proxy bastion, expose only the specific internal endpoints the agent needs through a public-facing nginx or Cloudflare Tunnel, with mutual TLS or HMAC signing for auth. This is more setup but does not require punching holes in your firewall for the whole VPS.

Either way, the Skill manifest's fetch_allowlist still gates which internal hosts the agent can call. Even with full LAN access, the agent only sees the URLs you explicitly allowlisted. This is how you safely give an agent access to one internal service without giving it the whole intranet.

How this connects to your full agent

Integrations are the glue between the agent's reasoning loop and the rest of your stack. The right ones make the agent feel like it lives inside your existing workflow. The wrong ones, or missing ones, leave the agent isolated and asking you to copy-paste between it and your real systems.

The right next read is openclaw docker on day 12, because production integrations belong inside a sandbox. Browser automation in particular is dangerous outside a container. The full deployment shape (Docker plus VPS plus monitoring) lives across days 12 and 13 (openclaw vps deployment).

If you only build one integration this week, do Slack outbound webhooks. The agent posting "morning briefing ready" or "long-running task done" to a channel you already check is the moment the integrations stop being abstract.