Sending WhatsApp Updates From Priority ERP: A Working Architecture

A WhatsApp integration with Priority ERP, meaning order, shipping and invoice updates sent to customers from Priority, takes five steps. None of them is a direct link between the two systems:

1. Set up the WhatsApp Cloud API on Meta: a WhatsApp Business account, a registered sending number and a permanent System User token.
2. Submit one UTILITY template per event (order confirmed, shipment sent, invoice issued) and wait for Meta to approve it.
3. In Priority, define the endpoint under BPM Maintenance > Webhook Definitions and add a BPM rule with a Webhook action on the document's status. This needs the Webhooks module.
4. Run a small middleware service that checks the priority-bpm-token header, queues the event, reads the missing details through the REST API and normalises the phone to E.164.
5. Send the template with POST /{phone-number-id}/messages, record the delivery status Meta reports back by webhook, and write permanent failures to the customer card.

The request sounds simple: when a shipping document is created in Priority, notify the customer on WhatsApp. Both sides expose an API, so it looks like a direct connection. In practice a direct connection will not work - not because of a technical limitation, but because of three requirements neither side provides.

This assumes familiarity with Priority webhooks and WhatsApp Cloud API setup.

Why not to connect them directly

You can define a Priority webhook pointing at any URL. It is tempting to point it straight at Meta's Graph API. That will not work, for four reasons:

1. Payload shape. Priority sends JSON in its own format, organised by form. Meta requires a completely specific structure with messaging_product, to, type and a components array. There is no way to bridge them through configuration.
2. Authentication. Meta requires a System User token in an Authorization header. Priority sends its own token in a priority-bpm-token header. These are different mechanisms.
3. Phone normalisation. The number on a customer card is almost never in E.164 format.
4. No retry. Priority has no documented retry policy. If Meta returns a transient error, the message is simply lost and nobody finds out.

So the architecture is always three parts, never two.

The architecture

Priority (BPM rule)
   → webhook →
Middleware service (queue + mapping + log)
   → Graph API →
WhatsApp Cloud API

1. The Priority side

Define an endpoint in the Webhook Definitions form under BPM Maintenance, then a BPM rule on the relevant document's flow chart with action type Webhook.

Send little in the body: the document number, the customer number and the event type. Not every field. The reason - any extra field you need later requires editing the rule inside Priority, which usually needs access you do not have. Fetch the rest over the REST API.

If there is a business condition - only customers who consented, say - put it in the rule's condition inside Priority rather than in your code. Less traffic and fewer places to check.

2. The middleware

This is the component doing the real work:

• Validates priority-bpm-token and rejects anything without it. It is the only protection - without it, anyone who discovers the URL can make you send messages.
• Writes to a queue and responds immediately. Never call Meta inside the webhook.
• Enriches - pulls what is missing from Priority: customer name, phone, document details.
• Normalises the phone to E.164.
• Maps the event type to a template name and variable values.
• Sends, logs and retries according to the error code.

3. Phone normalisation is not a detail

The phone field on an ERP customer card contains, in practice, anything: 052-1234567, 0521234567, 972521234567, +972-52-123-4567, sometimes two numbers in one field. Meta accepts only E.164. The build walkthrough is in how to create a WhatsApp bot.

The practical rules for Israel: a number starting with 0 - replace it with +972; a number starting with 972 - prefix a +; strip spaces, hyphens and parentheses. A number that does not resolve - do not send, flag it for review. Do not guess. For current build and running costs, see how much a chatbot costs.

What you are allowed to send: templates only

This is the point that breaks plans. You are initiating the message - the customer has not written to you - so the 24-hour window is closed by definition. Free text is rejected with error 131047. Every such notification must be an approved template.

The design consequence: every event type needs its own pre-approved template, in every language. You cannot compose dynamic text - only substitute values into positional variables {{1}}, {{2}}.

So the template set has to be designed before any code is written. For example:

Keep them UTILITY. These are operational updates, so they are cheaper and clear approval faster. The easy way to lose that is adding a URL button to your website - Meta will reclassify as MARKETING. If you need a tracking link, put it in the body as plain text.

Handling failures

Not every error is handled the same way. A practical split by Meta's error codes:

Error 131026 - "no WhatsApp" - is useful business information. It is worth writing back to the customer card so the system knows next time that this channel is unavailable and falls back to email or SMS.

No Webhooks module? Poll with $since

Priority webhooks require the Webhooks module, and plenty of installations do not have it. The fallback is a scheduled job: every few minutes the middleware asks the REST API for shipping documents (or orders) changed since its last run, using the $since query option, and treats each new status as an event. The cost is a delay of a few minutes and one call per run, far below Priority Cloud's limit of 100 calls a minute.

Version 26.0 adds one more tool worth knowing: Priority keeps failed webhook deliveries in the Webhook - Error Log under BPM Maintenance for 7 days. It tells you that a call failed; it does not resend it. The daily reconciliation job is still what closes the gap.

What happens when the customer replies?

A customer who answers a Priority update on WhatsApp opens a 24-hour customer service window. Their message does not go to Priority; it arrives at the webhook URL configured in your Meta app, which is the middleware. Inside that window you may reply with free text, so the replies need an owner before launch:

• Route them to a person, for example a shared inbox or the sales rep on the customer card.
• Or hand them to a bot that answers the common questions (order status, delivery time) from Priority data. The pattern is in AI chatbot for WhatsApp.
• Recognise opt-out words ("stop", "הסר") and stop sending to that number on every channel.

Updates with nowhere for the reply to go are worse than none: the customer writes back, nobody answers, and the next template reads like spam.

How much does a WhatsApp integration with Priority cost?

One event type, such as shipping notices, with the middleware, the templates and the retry logic is a single-workflow automation on my pricing page: $300 - $1,800. Several event types with replies routed to a bot are a multi-step build: $1,800 - $8,000. On top of that, Meta bills template messages per delivered message, by category and country; the details are in WhatsApp Business API pricing.

What not to do

• Do not send without consent. An operational update about an order the customer placed is accepted; using the same pipe for marketing content is something else entirely, both legally and in terms of Meta's quality rating - which is what causes templates to be paused.
• Do not put the Meta token in Priority. It belongs to the middleware only.
• Do not rely on the webhook alone. Priority has no documented retry. A daily job that scans the last day's documents and verifies a message was sent for each is what makes this reliable.

Sources

• Webhooks - Priority developer documentation
• Querying Data ($since) - Priority REST API documentation
• WhatsApp Cloud API - Meta for Developers