Detect a non-functional whatsapp integration
The platform recognizes, without waiting for a customer complaint, that a WhatsApp number has stopped working — an expired token, a restricted number quality, or repeated webhook failures — and surfaces it to Admins through the generic FR-15 health pipeline.
When this happens: (A) ChannelHealthCheckJob's probe. (B) A real send fails. (C) Meta's phone_number_quality_update or account_alerts webhook fires.
How it works
ChannelHealthCheckJobprobes the number's metadata endpoint.- EasyCRM returns
401— the system-user token was revoked (e.g. the Owner removed the app's access in Meta Business Manager). - Normalizes the response to
TokenExpired, movesRequiresReauthimmediately (not waiting for a failure count), and notifies Admins with a Re-authorize deep link.
Other paths
Number quality restricted
EasyCRM sends a phone_number_quality_update webhook with the rating now RED. Normalizes to NumberRestricted, reports it as a passive failure signal, and — once the consecutive-failure threshold is crossed — moves the connection to Degraded or Error and notifies Admins with the guided fix This number/account has been restricted by the provider
Quality recovers
EasyCRM sends a phone_number_quality_update webhook with the rating back to GREEN. Treats it as a recovery signal; if the connection was Degraded/Error because of NumberRestricted, it returns to Active and Admins receive the recovery notification.
If something goes wrong
Messaging-limit alert without a broken connection
EasyCRM sends an account_alerts webhook about a tier-increase eligibility failure. EasyCRM records it in the error history as informational; State does not change, since a capped tier is not a broken connection.
Good to know
- A clearly rejected credential moves the connection to
RequiresReauthimmediately, bypassing the consecutive-failure counter. - Quality-rating changes are Meta's own vocabulary (
GREEN/YELLOW/RED) and are only ever a passive signal — the health pipeline they feed is entirely FR-15's.