How to Connect OpenClaw to Zalo Personal - Unofficial Account Automation

The Zalo Personal integration exists for people who need a personal-account path, but the official docs do not sugarcoat the tradeoff. It is experimental, unofficial, runs through native zca-js inside OpenClaw, and may result in account suspension or ban. That warning belongs at the top because it should shape the whole deployment decision.

What the official docs support

The docs describe the channel as an in-process integration for a personal Zalo user account, not the official Bot API. It supports direct messages, optional group access, pairing, and directory lookups for peers and groups. Outbound text is chunked to around 2000 characters and streaming is blocked by default.

This is only the right path when the official Zalo Bot API is not available for the use case and you are comfortable accepting platform risk. The upside is that everything stays inside OpenClaw without an external CLI binary, and the docs show a clear flow for QR login, allowlists, and group controls.

What you need first

• Acceptance of the unofficial integration risk
• A gateway host where you can scan a Zalo QR code
• A plan for whether groups should be open, allowlisted, or disabled
• Numeric IDs or exact names for peers and groups when allowlists matter

Recommended setup flow

Treat this channel like a controlled experiment. Get login working, keep policies strict, and only then decide how much group surface you really want.

1. Run openclaw channels login --channel zalouser and scan the QR code from the gateway machine. The docs make it clear that no external zca or openzca CLI is required anymore because the integration now runs entirely inside OpenClaw.
2. Enable the channel with channels.zalouser.enabled true and keep dmPolicy on pairing. Restart the gateway so the stored login state and the channel runtime come up together.
3. Use the directory commands early. openclaw directory self, peers list, and groups list help you discover the stable IDs that are much safer for allowlists than display names, especially when you later restrict access to specific users or groups.
4. If you need group support, choose the policy explicitly. The docs say groups default to open, which may be more permissive than you want. allowlist mode plus channels.zalouser.groups and groupAllowFrom is usually the better production shape.
5. Only enable dangerouslyAllowNameMatching if you truly need break-glass compatibility. The docs call it out as a risky mode because names are mutable and unresolved names are otherwise ignored for authorization.

{
  channels: {
    zalouser: {
      enabled: true,
      dmPolicy: "pairing",
      groupPolicy: "allowlist"
    }
  }
}

Access, safety, and operational notes

This channel exposes a lot of useful control, but the defaults matter. Pairing is the DM default, group policy can be tightened to allowlist, sender checks can fall back from groupAllowFrom to allowFrom, and mention gating can be controlled per group. That is enough to keep a risky channel reasonably contained.

The docs also mention best-effort typing events, reactions, and delivery acknowledgements. Those are nice extras, but the real operator takeaway is to keep a close eye on login persistence and to re-login cleanly if the session stops sticking after an update or host change.

How to verify it is working

After login, test one DM and one group path separately. If allowlists do not resolve the way you expect, switch to numeric IDs before you debug anything else. The docs explicitly recommend IDs over names for long-term stability.

Common gotchas

• This is an unofficial integration and may risk account suspension
• Groups default to open unless you tighten groupPolicy
• IDs are safer than names for allowlists and group matching

If you want the operator version with tighter rollout checklists, safer defaults, and more production patterns, The OpenClaw Playbook is the easiest shortcut.