WhatsApp Contact Validation from Salesforce

Editorial illustration of a CRM console checking a quiet phone through a secure API gateway and returning review statuses.

A phone number in Salesforce does not tell a sales team whether WhatsApp is a viable channel. Checking manually creates another tool switch and leaves no consistent status for the next person or automation.

We built an Apex callout service that sends a normalized number to the Meta WhatsApp Cloud API, interprets the response, and returns an actionable result to Salesforce.

The integration pattern

The workflow has five deliberate steps:

  1. Normalize the CRM phone number before the request.
  2. Run an authenticated Apex HTTP callout.
  3. Parse successful responses and known error conditions, including 131026.
  4. Map the result to available, unavailable, or review required.
  5. Let Salesforce Flow or an Einstein Bot dialog decide what happens next.

Integration route: Salesforce contact, authenticated Apex HTTP callout, Meta API response, and the status returned to the Salesforce contact

The callout is exposed through @InvocableMethod, so the channel check can be reused without duplicating API logic across Flows. HttpCalloutMock covers the response paths in tests.

Apex class with InvocableMethod and mapStatus, tested with three HttpCalloutMock responses that map to available, unavailable and review required

Why “review required” matters

An API error is not always proof that a contact can never use WhatsApp. Formatting, permissions, account state, and temporary platform conditions can all affect the result. A reliable integration stores the reason alongside the status and avoids forcing an ambiguous signal into a yes-or-no field.

Status router sending an API result to three states: available, unavailable, and review required

What was verified

The Salesforce sandbox implementation verified the outbound callout, response parsing, handling of known failure conditions, and delivery of a usable status back to the CRM. This work was documented as Ticket 1 in the project runbook.

The case does not claim unmeasured conversion or time savings. Its verified value is architectural: the check runs inside Salesforce and produces a traceable signal that downstream automation can use.

Be precise with “silent validation”

Whether a validation path is completely invisible to a recipient depends on the exact Meta endpoint, message/template behavior, and current account configuration. Those conditions must be verified before publishing a “zero visible messages” claim. A production design should treat the API response as evidence with provenance, not as a permanent truth.

For a review of your CRM integration path, status model, and failure handling, book an architecture audit.