Zammad WhatsApp channel

Every WhatsApp conversation in Zammad passes through three Meta objects and one Zammad endpoint. A Meta business portfolio holds the WhatsApp Business account, and that account owns the phone number customers message. A Meta app, registered under the same portfolio, uses the WhatsApp Cloud API to send and receive messages on that number. Zammad does not connect to WhatsApp users directly. It connects to the Cloud API through the app, so the first design decision is which portfolio and app will own the number, who holds administrator access to each, and how that access is removed when staff change roles.

Inbound messages start with a webhook. When a customer writes to the business number, Meta sends an event to a callback URL you register in the Meta app. That URL must be publicly reachable over HTTPS, so the Zammad host or the reverse proxy in front of it has to accept traffic from Meta on the public internet. Confirm the exact verification handshake, the required certificate chain, and any firewall or allowlist rules against current Zammad and Meta documentation during scoping. Once the event arrives, Zammad creates a new ticket or appends an article to an existing one, so the endpoint's availability directly affects whether customer messages reach agents.

Outbound replies follow the same API in the opposite direction. When an agent answers a WhatsApp ticket, Zammad calls the Cloud API using credentials taken from the Meta app. These typically include an access token and identifiers for the app and the phone number, and the webhook verification uses its own secret value. The field names, the screens where each value is found, and the token type that Zammad accepts can change between releases, so treat any list in an internal document as provisional until someone has checked it against the Zammad channel settings and the Meta developer console on the day of the build.

Plan for the points where this flow fails quietly. Access tokens expire or get revoked when an admin leaves, and the owner of token rotation should be named before go-live. Meta also applies its own messaging rules, including conditions under which a business may reply freely and when it must use approved message templates. Confirm those rules in the current Meta documentation, because an agent reply that Meta refuses will look like a Zammad fault unless the team knows where to check. Finally, write a short runbook covering webhook outages, token failures and how to test with a non-production number before customers are routed to the channel.

Self-hosted Zammad has no license fee, since it is licensed under the GNU Affero General Public License version 3. WhatsApp messaging is different: Meta bills for it, and those charges sit outside Zammad's pricing entirely. Finance leads should model the WhatsApp channel as its own budget line, separate from the helpdesk. The optional Zammad self-hosted support subscriptions (Business, Enterprise and Corporation) are priced on Zammad's pricing page and are a separate decision. The recurring and one-time costs that matter most for the channel are Meta's messaging charges, phone number costs, the infrastructure that hosts Zammad and its webhook, and the labor to set up and support the channel. Zammad does not set any of these figures, so the budget depends on numbers you collect yourself.

The largest variable cost is Meta's charge for WhatsApp messages or conversations under its current pricing. Before you budget, confirm three things on Meta's pricing page: the billing unit (per message or per conversation), the category rules that decide how each conversation is priced, and the per-region rates for the markets you will serve. Rates depend on region and category and Meta revises them, so record the date you checked. This page does not give a Meta rate. To estimate the line, multiply your expected conversation volume by the rate for each region and category you will use. Ask your support lead how many conversations customers start versus how many your team starts, because those flows may be priced differently and change the total.

The WhatsApp Business phone number is a recurring cost tied to your Meta setup. Confirm with Meta whether the number type you need carries a fee, whether any provider charges apply, and whether an existing number can be moved to the channel. Hosting is the second recurring line. Zammad needs PostgreSQL 15 or newer, Redis 7 or newer and a reverse proxy such as Nginx or Apache, and the webhook needs a publicly reachable HTTPS endpoint. Elasticsearch is optional but strongly recommended, and Memcached is needed when Zammad runs as several instances. Estimate the servers, storage, backups, certificates and monitoring for the environment that will carry the channel, and size the webhook for your peak inbound volume, not the average.

Labor is usually the largest one-time cost. It covers the Meta app and business verification steps, webhook configuration, message template submission and approval, channel testing, agent training and runbooks for failed deliveries. Setup is one-time, but monitoring, template updates, responses to Meta policy changes and Zammad upgrades recur. Ask any partner for an itemized, fixed-scope quote that lists these tasks, who holds the Meta business account and credentials, what is handed over, and whether post-launch support is included or sold as a retainer. Your internal team's time should appear in the model too, even when the work is done in-house.

Turn these inputs into one model with a row for each cost: Meta messaging by region and category, the phone number, hosting, one-time setup labor, recurring support labor and any optional Zammad support subscription. Run it at your expected volume and at a higher volume case, so the finance team sees how the Meta line scales. Before approving the budget, confirm the rates and category rules with Meta on the day of the decision, and recheck them at each renewal. Keep the model with the scope document, because changes to channel volume or scope will shift the largest lines first.

The WhatsApp channel needs five recurring tasks after go-live, and each one needs a named owner before handover. Zammad holds the conversations, but the channel also depends on a Meta app, a Meta business account, a public webhook endpoint and the platform beneath Zammad, which includes PostgreSQL, Redis and the reverse proxy in front of the application. Those layers usually belong to different teams. Write the ownership split as a one-page matrix that names a person or team for each task, with a backup for each, and review it at every handover. The owners described below are an illustrative starting point to adapt to your organization.

Webhook delivery is the task most likely to fail silently. Meta sends inbound messages and status updates to the webhook URL you configure, and if that endpoint returns errors, a customer's message may never become a ticket. Assign the platform team to alert on error responses at the reverse proxy and on failed background jobs in Zammad. Assign the Zammad administrator to review failed outbound sends each working day in the channel and in the logs. Confirm in Meta's current documentation how it retries undelivered webhooks and how long it keeps them, because that retention window sets how far back you can recover missed messages.

The Meta access credential should rotate on a schedule your security team sets from your own policy and Meta's current guidance for your app type, which you should confirm. Rotation changes a live channel. The platform engineer stages the new credential, the administrator sends a test outbound message, and the old credential is revoked only after that test passes. Separately, one named person should watch Meta Business Manager notifications for template approval results and message policy changes. A rejected template or a policy change can stop outbound messages even when the code and infrastructure are healthy, so that person needs a direct route to the business owner and the support lead.

Zammad upgrades need the same discipline. Read the release notes for the version you run before scheduling any upgrade, and check whether channel-related changes affect your configuration. Test inbound and outbound WhatsApp flows on a staging instance connected to a Meta test setup before production. Security fixes can be published on more than one release line at the same time, so track both the line you run and its security advisories. Each month, the business owner should compare conversation volume and message counts with the Meta charges on the invoice. Check those charges against the Meta pricing that applies to your account and region, because costs depend on message category and that pricing can change.

A webhook outage runbook should be short enough to follow during an overnight incident. Include the alert that starts it and who is paged, a check that the endpoint answers on the public hostname with a valid certificate, a review of reverse proxy and application logs and the Zammad background job queue, and a check of the webhook subscription and verification settings in Meta. Add a decision point for replaying missed events, using the retention window you confirmed with Meta. Name who tells agents and the business owner which customers may be waiting, and define the criteria for closing the incident. Rehearse the runbook once in staging before go-live so the first real use is not the first test.