Integrate HookMyApp

HookMyApp connects the user's own WhatsApp number and Instagram account to their code: inbound events are forwarded to their code, and their replies go out over Meta's official API. Outbound sends route through the HookMyApp gateway (https://gateway.hookmyapp.com/meta/...): the user's app carries a minted hmat_ gateway access token, the gateway swaps it for the underlying Meta token server-side, and the path after /meta is verbatim Meta Graph API. This skill teaches AI coding agents how to drive the @gethookmyapp/cli to integrate a user's app with either a sandbox account (for dev and testing) or their own channel. WhatsApp uses Meta Embedded Signup; Instagram uses direct Instagram OAuth. The CLI owns credential issuance, tunnel lifecycle, and webhook configuration. For a single own-channel integration your code never needs to call the HookMyApp API directly; SaaS builders whose backend must manage customers at runtime use the REST API.

Direct Meta access still works. Integrations that already call https://graph.facebook.com with their own Meta token are unaffected. The gateway with a minted hmat_ access token is the recommended path for new setups: the access token is scoped to one channel and revocable.

Agent Guidance

Key Principles

• The CLI is the source of truth. Never embed credentials inline in generated code. Run hookmyapp sandbox env --write .env or hookmyapp channels env <channel> --write (which exports the channel's current gateway hmat_ access token — only channels token --rotate mints a new one) and let the user's app read from environment variables.
• There is no environment to select. Every command runs against the live HookMyApp service. Pass --workspace <id> only when the user has multiple workspaces and a command must hit one other than the active default.
• Browser steps cannot be automated. login and channels connect both open browser tabs the human must complete. Do not pretend to automate them — hand the terminal back with a clear instruction. Exception: hookmyapp login --email <addr> is a browser-free login (an OTP code arrives at the human's email; they paste it back) — prefer it in agent/CI contexts. See references/auth.md.
• Connecting a real channel? First ask WHOSE channel it is. Two distinct connect flows exist and they are not interchangeable. (a) The user's own team/product channel — their company's WhatsApp number or Instagram account — connects via hookmyapp channels connect (browser Embedded Signup / OAuth) into a team workspace. (b) An end-customer's channel — the user runs a SaaS and their customers bring their own numbers/accounts — connects via a customer workspace plus an onboarding link (customers onboarding-links create) that the end-customer opens; onboarding links can ONLY target customer workspaces, and the backend rejects a link pointed at a team workspace. When the user says "connect WhatsApp/Instagram" and the intent is not already obvious from context, ask one question before acting: "Is this your own team's channel, or a channel your customers will connect?" — then route to (a) or (b). Never mint an onboarding link for the user's own channel.
• Sandbox is not your own channel. Sandbox is a HookMyApp-hosted test account with 6 env keys, no templates, and recipient pinned to the session phone. Your own channel is your WhatsApp number (7 env keys and template support) or Instagram account (6 env keys and no templates). Authorize it with channels connect, then export its runtime environment with channels env. The two are not interchangeable — pick one based on the user's goal before generating code.
• MCP is optional; the CLI is never blocked. Setup installs the CLI — that is the whole requirement. The MCP server is a convenience for agents that prefer tool calls, and hookmyapp login configures it automatically for Claude Code. Because MCP tools resolve at session start, a server installed mid-session stays dormant until the next session: that is expected, not a failure. When mcp__hookmyapp__* tools are absent or the connection is unhealthy and a shell is available, do the task with the CLI and mention that a restart activates the tools — never tell the user the task cannot be done while the CLI can do it. (Shell-less agents are the one exception: without a working MCP connection they should say exactly which capability is missing.) Repair steps: references/mcp.md.
• Your own channel has two webhook-delivery flavors: CLI tunnel OR your own URL. A connected channel can receive inbound webhooks via either (a) hookmyapp channels listen (the CLI provisions a per-channel Cloudflare tunnel — no public HTTPS URL required, designed for local dev / self-hosted agents / 24/7 hobby projects) or (b) hookmyapp channels webhook set <channel> --url https://... (your own public HTTPS endpoint, the classic deployed pattern). Pick CLI when the user is developing on localhost or running an always-on self-hosted agent (e.g. on a personal server or Raspberry Pi); pick URL when the user has a deployed backend ready to accept inbound webhooks. The two are mutually exclusive per channel — setting a URL while the CLI is listening evicts the CLI (it exits cleanly with a notice).
• Check notifications every session. status returns notifications[] — messages from HookMyApp for this account: problems detected (failing webhook delivery, disconnected channels, usage limits), fixes applied, required updates, and product announcements. Relay every open notification to the human in your first reply, then mark it seen with acknowledge_notification (CLI: hookmyapp notifications ack <id>) so it stops repeating. After any send failure, re-check (status or hookmyapp notifications) — same sequence: relay any new notification to the human first, then acknowledge it. Notification fields that shape how you relay: ackScope: "user" means your ack clears the notification only for YOUR human — other members of the organization each see and dismiss their own copy, so acking never hides anything from anyone else; ackScope: "org" means one ack clears it for the whole organization and records who saw it — acknowledgedBy on an org notification is that receipt ("acknowledged for the org by " — it means their agent relayed it, NOT that the underlying problem was fixed); personal: true means the notification is addressed to your human specifically (no one else in the organization can see it) — say so when relaying, e.g. "this one is addressed to you directly."