Provider picker that refuses a switch that would break you

Each provider declares what must be true before it can carry a channel, and the server checks that against live account state before writing the change.

What it is

A declarative catalogue lists every selectable provider, the channels it can carry, and its prerequisites (a phone number, an approved A2P 10DLC campaign, a verified sending domain, a connected CRM sub-account, platform credentials). A server-only evaluator loads the account's real facts and returns a yes/no per provider with the specific unmet prerequisite in plain language.

Also called: why can't I pick Twilio · A2P required · verified domain required · prerequisites

See it
Provider picker that refuses a switch that would break you
Day rate
$400
Days figured
8
Crew size
3
Fuel & equipment
$300
Finished 2 days early — $1,400 back to the crew
Provider cards with a green 'Recommended' chip, and a blocked card showing an amber blocker row: 'Approved business texting registration (A2P 10DLC) — US carriers block business texts from unregistered numbers.' Sample data — no customer information appears here.
How it works
  1. 1The browser renders the picker from the static catalogue (no network, no secrets).
  2. 2The server loads one snapshot of org facts: account phone, a2p_status, verified Mailgun domain, GHL location + token, platform credentials.
  3. 3evaluateChannel returns each provider with eligible true/false and a list of blockers, each with a label and how to clear it.
  4. 4setChannelProvider re-checks eligibility before writing, and refuses with the blockers attached.
  5. 5On success the chosen provider becomes priority 1 and the previous actives are demoted to fallbacks rather than deleted.
Why we built it

The header states the reason plainly: 'The prerequisites are not paperwork. Switching an org's texting to Twilio before its 10DLC campaign is approved doesn't degrade delivery — US carriers drop the messages, and the tenant finds out when a customer says they never got the update. A picker without this check would be a button that breaks messaging while reporting success.' The catalogue adds why the check has to be server-side: the static half is browser-safe so the picker can render, 'and the verdict is server-only so a client cannot talk its way past a prerequisite by sending a flag.'

The problem
  • A provider switch could be accepted while silently dropping every text afterwards.
  • A demoted provider used to be deleted, leaving no fallback and no undo.
Sound familiar?
What you get
The UI can say 'you need A2P approved first' instead of failing after the fact.
Switching keeps the old provider as a fallback so the change is reversible.
Every switch writes a comms_requests audit line naming the actor.
What's inside

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →