Skip to content

feat(notifications): Baileys wa-bridge delivery for WhatsApp invites - #463

Merged
islandbitcoin merged 2 commits into
mainfrom
feat/invite-wa-bridge-delivery
Aug 3, 2026
Merged

feat(notifications): Baileys wa-bridge delivery for WhatsApp invites#463
islandbitcoin merged 2 commits into
mainfrom
feat/invite-wa-bridge-delivery

Conversation

@islandbitcoin

Copy link
Copy Markdown
Contributor

Env-switched WhatsApp delivery provider: when WA_BRIDGE_URL + WA_BRIDGE_SECRET are set, invite WhatsApp messages go through the flash-support-infra wa-bridge's authed POST /send (Baileys, plain text + invite link — no Meta template needed); otherwise the existing Twilio template path is unchanged.

Why: no environment has a Twilio WhatsApp sender provisioned (TWILIO_WHATSAPP_FROM unset in TEST and PROD — only the Verify service is wired), so WhatsApp invite delivery has never worked. The bridge endpoint is deployed on pulse-server and smoke-tested (authed, timing-safe compare, 401 negative-controls, content never logged).

Scope: TEST/dev delivery now. Prod should provision the official Twilio WhatsApp sender + approved template before launch, or deliberately opt into the bridge.

Tests: 6 new (transport auth/payload/error/fallback + body selection). Suite green; tsc + eslint clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_01C7z7o9J18BWbUnYJcemMtg

bobodread876 and others added 2 commits August 1, 2026 17:54
No env has a Twilio WhatsApp sender provisioned (TWILIO_WHATSAPP_FROM is
unset in TEST and PROD — only the Verify service is wired), so WhatsApp
invite delivery has never worked. Add an env-switched provider: when
WA_BRIDGE_URL + WA_BRIDGE_SECRET are set, WhatsApp messages go through the
flash-support-infra wa-bridge's authed POST /send (Baileys) as plain text
with the invite link (no Meta template needed); otherwise the existing
Twilio template path is used unchanged. 15s timeout, message content never
logged (invite links carry one-time tokens).

Intended use: TEST/dev delivery now (bridge endpoint deployed + smoke-tested
on pulse-server). Prod should provision the official Twilio WhatsApp sender
+ approved template before launch, or deliberately opt into the bridge.

Tests: bridge transport (auth header, payload shape, non-ok, network error,
unconfigured fallback proves the bridge is the succeeding path) + invite
body selection (plain text w/ link vs template blob). 4+2 new, suite green.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01C7z7o9J18BWbUnYJcemMtg
…very

The wa-bridge feature-gate was evaluated independently in two places —
transport selection (sendWhatsApp) and invite body selection
(sendInviteNotification). Identical today, but two sources of truth for
one decision: if they ever drifted, a plain-text body could be sent
through the Twilio template path (or a template blob through the bridge
as literal text) with no test catching it.

Collapse both onto one exported getter, waBridgeConfig(), which also
warns when exactly one of WA_BRIDGE_URL/WA_BRIDGE_SECRET is set (a
partial config that previously fell back to the broken Twilio path
silently). Add getter unit tests incl. the partial-config case; update
invite-body.spec's module mock to expose the getter.

9 unit tests, tsc --noEmit, eslint all green.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01C7z7o9J18BWbUnYJcemMtg
@islandbitcoin
islandbitcoin merged commit 8e52708 into main Aug 3, 2026
15 checks passed
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.

2 participants