Sending WhatsApp Updates From Priority ERP: A Working Architecture

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 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.

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.

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.