¶ Username LIDs
Cloud API cannot address username LIDs such as @lid. A routing id is not a phone-number target.
Operations
¶ Cloud API Routing Issues
A returned wamid is not proof of delivery. Cloud API cannot address username LIDs or groups, and Graph may accept a bad-looking send while the message never lands.
Cloud API limitation
Route through
services/transport.py
Silent non-delivery risk
Routing rule
¶ Resolve the transport; do not guess it.
Always route sends through services/transport.py. Do not read conversations.transport directly, and do not strip WhatsApp suffixes to force a target into the Cloud API shape.
Failure mode
¶ Some addresses do not belong on Graph
The first check for a one-grey-tick Cloud API report is the recipient id. The bad path is quiet enough to look like a delivery delay.
¶ Groups
Cloud API cannot address group JIDs such as @g.us. Group delivery must not be forced through Graph.
¶ False success
Graph may return a wamid after accepting a malformed phone-looking value, while the recipient never receives the message.
Triage
¶ Classify the target before chasing status
Use these checks before treating the report as a stuck send, connector issue, or generic delivery regression.
Recipient idDoes it end in
@lid or @g.us?
Routing pathDid the send resolve through services/transport.py?
Graph responseIf Graph returned a wamid, still verify whether the address was valid for Cloud API.
Provider fitIf the target requires Baileys behavior, do not coerce it into a Cloud API send.
Decision path
¶ When the send looks accepted but never delivers
¶ Inspect the address suffix
@lid and @g.us are expected Cloud API failures. Do not diagnose them as ordinary delayed delivery.
¶ Check for suffix stripping
If the suffix was removed, the result may look like a phone number even though it no longer represents a valid Cloud API destination.
¶ Fix the caller path
Route through services/transport.py so coexistence, Baileys-only cases, and Cloud API channels all follow one decision point.
Known production behavior
¶ Expected versus suspicious
Expected: Cloud API cannot deliver to @lid or @g.us. Investigate when the system claims routing resolved to Baileys but the send still behaves like Cloud API, or when a caller bypasses services/transport.py.
CI and managed databases
¶ Post-deploy checks read API aggregates, not the database
Managed cloud databases may refuse connections from ephemeral CI runners or restrict trusted sources, so expect network-blocked runners. The Deploy DigitalOcean workflow's post-deploy audit therefore queries a numeric-only aggregate endpoint, GET /api/v1/healthz/channels, to verify WhatsApp line counts before and after rollouts.
¶ Numbers only
The endpoint returns only integers (connected, total, by_status) — never channel ids, phones, labels, or organization identifiers. Keeping audit responses identifier-free is what makes them safe to query from CI without extra credentials.
¶ Tolerant rollout
If the endpoint is not yet served (404), the rollout records a harmless empty baseline and emits a warning instead of failing the deployment. Any other non-200 response is an error.
¶ The general pattern
For deployment audits that only need tallies, expose a minimal aggregate endpoint that returns numeric totals rather than granting CI direct database access.