SKILL

Messaging Vendor Sandbox Tester

Purpose

Runs the 11 gate checks (Section B of messaging-vendor-phase-0-1-2026-04-23) against a vendor’s sandbox, trial, or test-mode endpoint before any live paid message is sent. Each gate gets a PASS / FAIL / NEEDS-IMPLEMENTATION status with evidence artifacts.

Sandbox-first is mandated by plan Section B.2: gate checks 3-11 must pass in sandbox before the first live paid message. Only gates 1-2 (10DLC brand + campaign approval) cannot be simulated in sandbox — those require the real production vendor account.

Prevents sending broken traffic live and catches integration bugs for free.

When to use

• Before Phase 1 smoke tests for any vendor (Telnyx, Bandwidth, sent.dm, Bird, LoopMessage, Linq)
• After a vendor’s API version change or webhook signature scheme update
• Regression check after changes to messaging-compliance-gate.js or webhook-sig-verify.js
• Once per week as part of the automated health check suite

Do NOT use as a substitute for live smoke tests (Phase 1); sandbox cannot verify real carrier delivery.

Inputs

Flag	Type	Required	Description
--vendor	string	yes	Vendor name from messaging_providers.name
--output	string	no	Path for evidence packet (default workspace/reports/vendor-sandbox/<vendor>-<date>.md)
--skip-10dlc	boolean	no	Skip gates 1-2 if TCR campaign approval is pending (default true)

Outputs

• Evidence packet at workspace/reports/vendor-sandbox/<vendor>-phase1-sandbox-<YYYY-MM-DD>.md with:
  • Timestamp, vendor, account info
  • 11 gate check results (PASS / FAIL / NEEDS-IMPLEMENTATION per gate)
  • Raw API responses, sample webhook bodies, screenshots where applicable
  • Per-gate remediation notes if FAILED
• Per-run log at workspace/logs/sandbox-tester/<vendor>-<epoch>.jsonl with every API call + response
• Update to messaging_providers.metadata.last_sandbox_run with timestamp + pass/fail summary

Gate checks implemented

1. 10DLC brand approved (skipped in sandbox unless --skip-10dlc=false)
2. 10DLC campaign approved (skipped in sandbox)
3. Outbound API test — sends via vendor sandbox endpoint
4. Inbound webhook — replays a known-good test event
5. Delivery receipt — verifies DLR webhook routes to messaging_delivery_events
6. STOP suppression — sends STOP keyword event + verifies subsequent send blocked
7. Quiet-hours enforcement — simulates 22:00 local send, verifies gate blocks
8. Per-phone cooldown — sends twice to same phone within window, verifies second blocked
9. Dedup via processed_webhook_events — replays same event twice, verifies short-circuit
10. webhook_audit_log + local-file fallback tested via simulated DB outage
11. Dead-letter + cost tracking — verifies fallback file + messaging_outbound_messages.cost_cents populated

Acceptance tests

• Running against sent.dm with an active sandbox API key returns ≥9 PASS (gates 1-2 skipped)
• Running against a vendor with no sandbox access returns NEEDS-IMPLEMENTATION for gates 3-11 and fails gracefully
• Evidence packet is a valid markdown file with all 11 gates listed (even if NEEDS-IMPLEMENTATION)
• Sandbox traffic never touches messaging_outbound_messages production rows (uses split_test_group=-1 sentinel or separate test table)
• Script exits with code 0 only if all non-NEEDS-IMPLEMENTATION gates PASS; otherwise exits 1

Rollback behavior

None needed — script is read-only from production perspective. Sandbox API calls are billed-as-test and do not produce real carrier traffic. If a test accidentally hits a live endpoint (bug), kill the process; no cleanup required since the vendor’s sandbox billing is separate.

Clean up test artifacts: rm -rf workspace/logs/sandbox-tester/<vendor>-* and the evidence packet if a run was invalid.

Related files

• Plan section B.2 (sandbox pre-prod track) and Section B (11 gate checks)
• Implementation script: tools/messaging-vendor-sandbox-tester.js
• Compliance gate: tools/messaging-compliance-gate.js (reused for gates 6-8)
• Webhook verifier: tools/webhook-sig-verify.js (reused for gate 4-5 sig check)
• Per-vendor sandbox endpoints: documented in each workspace/knowledge-base/<vendor>/API.md
• Testability audit: workspace/docs/VENDOR-TESTABILITY-AUDIT.md (which vendors have sandbox)

Vendor sandbox mode reference

Vendor	Sandbox endpoint	How triggered
sent.dm	Same /v3/messages endpoint with "sandbox": true in body	Appendix D.1 confirmed working
Telnyx	Separate sandbox messaging profile, or live endpoint with test credit	TBD at Telnyx onboarding
Bandwidth	Separate sandbox sub-account	Sales-led activation
Bird	Sandbox workspace on signup	Auto-provisioned
LoopMessage	Free 5-contact sandbox on signup	Auto-provisioned
Linq	Sandbox tier on signup	Auto-provisioned
Sendblue	Free 10-contact sandbox (inbound-only)	Auto-provisioned

Gate 3 “Outbound API test” will return NEEDS-IMPLEMENTATION for vendors whose sandbox specifics aren’t yet wired.