Use least privilege.
Prefer line API tokens for automation sends. Do not use workspace owner/admin tokens for server automations unless the workflow truly needs workspace routes.
Permissions
Keep API access, workspace access, and support access separate.
EZWhatsApp separates customer organization roles, line permissions, line API tokens, and creator support access. Integrations must respect those boundaries.
Permission surfaces
| Surface | Who uses it | What it controls |
|---|---|---|
| Workspace ID token | Logged-in owner, admin, or operator. | Admin/operator routes, line management, inbox actions, assignments, notes, workspace sends, and signed media reads according to membership and line visibility. |
| Line API token | Server-side automation owned by the client or agency. | One line's Channel API health, direct sends, URL media sends, and webhook configuration. |
| Line permissions | Client admins managing team access. | Which team members can see or operate specific WhatsApp lines in the workspace. |
| Creator support access | EZWhatsApp creator support under explicit break-glass session. | Support visibility for a customer organization when support access is active and audited. |
Agency implementation rules
Keep tokens server-side.
Never place ezw_line_... tokens in browser code, public no-code templates, screenshots, or tracked files.
Preserve line boundaries.
A line token sends from exactly one WhatsApp line. Multi-line routing requires an explicit client-side decision and separate tokens.
Use workspace APIs for human work.
Inbox reads, assignments, notes, signed media, and member actions belong to workspace routes with workspace identity.