Skip to content

Add WhatsApp error-code reference and broadcast triage to observe-whatsapp#8

Draft
posthog[bot] wants to merge 1 commit into
mainfrom
posthog-code/whatsapp-error-codes-broadcast-triage
Draft

Add WhatsApp error-code reference and broadcast triage to observe-whatsapp#8
posthog[bot] wants to merge 1 commit into
mainfrom
posthog-code/whatsapp-error-codes-broadcast-triage

Conversation

@posthog

@posthog posthog Bot commented Jun 29, 2026

Copy link
Copy Markdown

Summary

The observe-whatsapp skill instructed agents to "map error codes to remediation" and "translate error codes into user-facing guidance" but shipped no actual error-code table, and neither the references nor scripts/errors.js mentioned broadcasts/campaigns at all. This left a recurring diagnostic gap when triaging WhatsApp broadcast delivery failures — notably error 131049 ("healthy ecosystem engagement", Meta's per-user marketing-message cap).

  • references/message-debugging-reference.md — concrete WhatsApp Cloud API error-code → remediation tables: messaging limits/policy (131049, 130472, 131048, …), delivery failures (131026, 131047, throughput limits, …), template errors (132xxx), and eligibility/auth. Documents where codes surface (kapso.statuses[] for messages, error_details/error_message for broadcast recipients) and flags which codes are expected vs actionable.
  • references/triage-reference.md — a broadcast/campaign failure triage flow that reads from the platform API (broadcast counts → failed recipients → error codes), since broadcast delivery data is not in PostHog analytics.
  • scripts/broadcasts.js — new helper to list broadcasts, inspect one, and drill into failed recipients (with --failed-only) to read their Meta error codes.
  • scripts/errors.js / SKILL.md — pointers wiring the new broadcast path into the existing triage flow, scripts table, and file map.

Why

One user spent two sessions failing to diagnose a high WhatsApp broadcast failure rate (error 131049) because the skill meant for this triage had no error-code mapping and no broadcast coverage. This is a documentation/skill gap in this repo; the underlying broadcast detail-page load bug lives in the Kapso product app and is out of scope here (the new broadcasts.js reads the same data via the API as a workaround).

Test plan

  • npm run validate
  • npm run check:syntax
  • node scripts/broadcasts.js --help and arg-validation paths exercised.

Created with PostHog Code from an inbox report.

…tsapp

The observe-whatsapp skill told agents to "map error codes to remediation"
but shipped no actual table, and had no broadcast/campaign coverage — so
diagnosing a high broadcast failure rate (e.g. error 131049, Meta's
"healthy ecosystem engagement" marketing-message cap) had no guidance.

- references/message-debugging-reference.md: concrete WhatsApp Cloud API
  error-code -> remediation tables (messaging limits incl. 131049/130472,
  delivery failures, template errors, eligibility), plus where codes surface
  (kapso.statuses[] for messages, error_details for broadcast recipients).
- references/triage-reference.md: broadcast/campaign failure triage flow
  pointing at the platform API (broadcasts are not in PostHog analytics).
- scripts/broadcasts.js: list broadcasts, inspect one, and drill into failed
  recipients with their Meta error codes; --failed-only filter.
- errors.js: note pointing at broadcasts.js for campaign failures.
- SKILL.md: wired in the broadcast triage step, scripts table, file map.

Generated-By: PostHog Code
Task-Id: cc8ecff1-b9fa-4927-b4cb-80b97252a1b7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants