VENDOR-TESTABILITY-AUDIT — Out-of-Scope Vendor Testability Audit
Purpose: This document audits all messaging vendors that are outside the Phase 0/1 critical path. The purpose is to determine what is testable at zero or low cost today, what API patterns are worth borrowing, and whether any of these vendors should be elevated into the Phase 1 test set. This document is updated as new information is gathered.
Context
The Phase 0/1 test set includes: Telnyx, Bandwidth, sent.dm, Bird, LoopMessage, Linq. The vendors below are either too expensive for the current use case, in a different product category, or their evaluation would distract from the Phase 0/1 critical path. However, “out of scope” does not mean “ignore.” Each vendor is audited for:
- Whether it is testable at zero cost today (free tier, sandbox, read-only API audit)
- What features or API patterns could be borrowed into our existing integrations
- Whether the Phase 0/1 plan should be revisited based on new information
Out-of-scope vendor audit table
| Vendor | Category | Testable now? | Free tier | Why out of scope for Phase 0/1 | Features worth borrowing | Recommended Phase 0A action |
|---|---|---|---|---|---|---|
| Close.com | Sales engagement layer | Yes (14-day trial) | No, but trial covers full feature set | Redundant with OpenPhone+HubSpot for current team size (<10 reps); evaluation blocks Phase 0/1 focus | Predictive dialer integration pattern; HubSpot two-way sync model | Audit API + trial signup; document findings in workspace/knowledge-base/close/ but do NOT create an account yet |
| WhatsApp Business API | Channel | Yes (Meta Business trial) | WhatsApp Cloud API has free tier (1000 service msgs/mo) | International/bilingual sellers not current priority; Meta Business verification takes 2-3 weeks | Template-based messaging model, opt-in flow | Document in KB for future; do NOT onboard Meta Business unless seller market demands it |
| Unipile | LinkedIn + Instagram + Telegram | Yes (7-day trial + EUR 49 base) | 7-day trial | Social rail parallel to SMS; does not affect SMS cost equation | Unified inbox for non-SMS social channels | Audit API + note as Phase 4+ when investor/partner outreach scales |
| BetterPhone custom app | Potential in-house phone app | N/A (internal build) | N/A | Q3/Q4 2026 option; 1-3 month build distracts from vendor evaluation | Would use Telnyx or sent.dm as backbone once chosen | Deferred; no Phase 0A work |
| Sendblue | iMessage hosted | Yes (free sandbox, 10 contacts inbound-only) | Yes (sandbox) | Priced at $100/line, same as LoopMessage but fewer features; LoopMessage wins on feature parity | FaceTime Audio API patterns; reactions/tapbacks handling patterns | Audit sandbox API + KB pull for patterns borrowable into BlueBubbles handlers |
| Twilio | SMS/voice | Yes (already have active account) | Trial credits on new signup | Too expensive at $0.0083/segment for bulk SMS; keep Voice handler on port 18797 | Existing integration; good fallback; battle-tested webhook reliability patterns | No new work; existing Twilio Voice handler continues operating |
Detailed entries
Close.com
Category: Sales engagement + CRM layer
What it is: Sales-focused CRM with built-in calling, SMS, email sequencing, and predictive dialer. Competes with HubSpot Sales Hub. Current RERI stack: HubSpot + OpenPhone/Quo. Close.com would be a replacement or addition to one or both.
Why out of scope: For a <10-rep acquisition team, the additional seat cost (99/user/mo on top of HubSpot) is not justified by the dialer efficiency gains. Close.com evaluation would require a full CRM comparison, which is a Q3 project in its own right.
Free/trial access: 14-day trial with full feature access. No credit card required on signup (NEEDS VERIFICATION).
API patterns worth borrowing:
- HubSpot two-way contact sync model: Close.com’s sync handles field-level conflict resolution by “last write wins with timestamp” — a pattern our HubSpot-OpenPhone sync could adopt
- Predictive dialer queue management: rate limiting + abandon rate tracking patterns useful for bulk SMS send queue design
- Sequence branching on reply detection: their “stop sequence if replied” logic is similar to what
smart-outreach-worker.jsdoes manually
KB pull recommended: Yes. Pull Close.com API docs to workspace/knowledge-base/close/API.md during Phase 0A. Focus on: contact sync API, activity logging, and sequence management. Do not create a Close.com account; just read public docs.
Revisit trigger: If Henry decides to move the acquisition team to a dedicated sales CRM in Q3 2026, Close.com should be in the evaluation.
WhatsApp Business API (Meta Cloud API)
Category: Messaging channel (international + bilingual)
What it is: Meta’s WhatsApp Business Platform. Template-based messaging, similar to sent.dm’s architecture. Required for international contacts or Spanish-speaking seller outreach.
Why out of scope: RERI’s current seller/buyer database is primarily US-only. WhatsApp penetration in the US investor/seller market is low relative to SMS. The Meta Business verification process (2-3 weeks) would delay Phase 0/1 timeline. sent.dm already supports WhatsApp as a channel once Meta verification completes (see Appendix B of plan).
Free/trial access: WhatsApp Cloud API offers 1000 free service conversations per month. Business verification still required. Meta’s verification timeline: 1-5 business days for standard, up to 30 days for businesses with low Meta footprint.
API patterns worth borrowing:
- Template approval workflow: Meta’s category system (UTILITY vs MARKETING vs AUTHENTICATION) and approval pipeline is identical to what sent.dm wraps around it. Understanding it directly helps debug sent.dm template issues.
- Opt-in double confirmation flow: Meta requires explicit opt-in before any business-initiated message. Their consent model is stricter than US SMS TCPA and would raise our compliance standard if adopted.
KB pull recommended: Yes, but low priority. workspace/knowledge-base/whatsapp/ during Phase 0B when sent.dm’s WhatsApp channel unblocks.
Revisit trigger: If >20% of new contacts in any state speak Spanish as primary language OR if international investor outreach begins.
Unipile
Category: Unified social inbox (LinkedIn DMs, Instagram DMs, Telegram)
What it is: API-first platform that wraps LinkedIn, Instagram, Telegram, WhatsApp, Gmail, and Outlook into one unified inbox. Aimed at sales teams that work across multiple social platforms. EUR 49/month entry tier.
Why out of scope: Does not affect the SMS cost equation. Social channels are a Phase 4+ consideration when investor/partner outreach scales beyond phone-based sales. The acquisition team currently converts via phone + SMS exclusively.
Free/trial access: 7-day trial, full-feature. No credit card listed on site (NEEDS VERIFICATION).
API patterns worth borrowing:
- Multi-platform message routing: Unipile’s channel-agnostic send API (one endpoint,
channelfield switches between platforms) is architecturally cleaner than our current per-platform handlers. Worth studying for a future OpenClaw unified send abstraction. - LinkedIn message threading: their conversation ID persistence across sessions would improve our LinkedIn DM tracking if we ever add LinkedIn outreach.
KB pull recommended: Low priority. No action in Phase 0A. Add to Phase 4 backlog.
BetterPhone custom app
Category: Internal build (potential future product)
What it is: A custom iOS/Android app that would give RERI an in-house SMS/call interface, bypassing third-party per-message costs entirely. Estimated build: 1-3 months of engineering.
Why out of scope: Build timeline conflicts directly with Phase 0/1 vendor evaluation. Cannot evaluate an app that does not exist. The backend messaging infrastructure evaluated in Phase 0/1 would form the backbone of BetterPhone if it is ever built.
Free/trial access: N/A (does not exist).
Dependencies if built: Telnyx or Bandwidth as the carrier backbone (whichever Phase 2 selects). sent.dm for WhatsApp. The canonical data model in Section F of the plan (messaging_outbound_messages, etc.) is designed to be phone-app-compatible.
KB pull recommended: None. Deferred to Q3/Q4 2026.
Sendblue
Category: iMessage hosted service
What it is: Hosted iMessage-as-a-service. Like LoopMessage, but aimed at sales teams with simpler setup. Priced at $100/line/month flat with unlimited messages.
Why out of scope: Priced identically to LoopMessage ($99.99/line) but with fewer documented features. LoopMessage has FaceTime Audio API, reaction support, group messaging, and a more active developer community. Sendblue’s sandbox is inbound-only (no outbound sandbox), which limits gate-check coverage compared to LoopMessage.
Free/trial access: Yes. Free sandbox with 10 verified contacts. Inbound-only (cannot send from sandbox). This limits sandbox testing to gate checks G4, G9, G10 only.
API patterns worth borrowing:
- Group message threading: Sendblue’s group iMessage API (POST /api/v1/send-group-mms) uses a simpler payload structure than LoopMessage’s equivalent. The simplified thread_id approach could be backported into our LoopMessage handler.
- Tapback/reaction handling: their
reaction_typefield naming is cleaner than LoopMessage’s. Worth noting when building the BlueBubbles reaction handler. - Webhook retry policy: Sendblue documents an explicit 3-attempt retry with exponential backoff in their webhook docs. This is the pattern our handlers should implement (currently none do).
KB pull recommended: Yes. During Phase 0A, pull workspace/knowledge-base/sendblue/ with API.md and WEBHOOKS.md. Focus on API patterns for reactions and group messages. Do NOT create a production Sendblue account.
Revisit trigger: If LoopMessage pricing increases, or if Sendblue adds an outbound sandbox tier.
Twilio (current)
Category: SMS/Voice (active production account)
What it is: Already active in RERI’s stack. Handles Voice at port 18797 (workspace/webhooks/twilio-voice-handler.js). Previously handled SMS but was replaced by SalesMsg for bulk marketing sends.
Why out of scope for new testing: At 0.012 blended), Twilio is more expensive than Telnyx/Bandwidth for bulk SMS. It is kept as the Voice handler and as a fallback/failover SMS path but is not in the Phase 2 split test.
Free/trial access: Trial credits available on new signup. Existing account has production credentials in master.env. Do not create a second account.
API patterns worth borrowing:
- Signature verification pattern (HMAC-SHA256 on X-Twilio-Signature): the most battle-tested webhook verification pattern in the industry. All new vendor webhook handlers should mirror this pattern where the vendor supports it.
- Status callback URL design: Twilio’s per-message
StatusCallbackURL that fires on sent/delivered/failed transitions is the gold standard. When onboarding new vendors, request a similar per-message callback URL model. - TwiML for voice: the existing voice handler at port 18797 is production-stable. No changes needed.
KB pull recommended: None. Existing knowledge base at workspace/knowledge-base/twilio/ (if it exists) is sufficient. No new work.
Summary recommendation by vendor
| Vendor | Phase 0A action | Owner | Priority |
|---|---|---|---|
| Close.com | Pull API docs to KB only | Claude Code | P2 |
| WhatsApp (Meta) | Deferred to Phase 0B (tied to sent.dm WA channel) | Claude Code | P2 |
| Unipile | No action in Phase 0A | — | P3 |
| BetterPhone | No action; dependency on Phase 2 decision | — | P3 |
| Sendblue | Pull API docs + sandbox patterns to KB | Claude Code | P2 |
| Twilio | No action; existing handler stable | — | Ongoing |
How to elevate a vendor from this list to Phase 1 test set
Any vendor on this list can be elevated if:
- Henry explicitly adds it to the test set (written in SESSION-AUDIT.md or Discord
#ops) - A sandbox or trial with full send/receive capability is confirmed available
- All 11 gate checks can be run against that sandbox before any live send
- The Phase 0A KB pull is completed first
If elevated, the vendor gets a row in messaging_providers (via 001-provider-seeds.sql amendment), a KB directory, and is added to the Phase 0B onboarding sequence.
Change log
| Date | Change | Author |
|---|---|---|
| 2026-04-24 | Initial document created from plan Appendix A | Claude Code |
Version: v1 Owner: Henry Hill Last updated: 2026-04-24 Sourced from: messaging-vendor-phase-0-1-2026-04-23 plan Appendix A