Sensible defaults for a brand-new account

An account whose provider rows are missing still sends, through a default chain that reflects current policy rather than legacy behaviour.

What it is

PLATFORM_DEFAULT_CHAINS names the fallback order per capability: email is Mailgun then Resend, SMS is Twilio only, voice is deliberately empty, payments is Stripe. Explicit bindings always beat the defaults, so a tenant with a configured chain is unaffected.

Also called: default provider order · works out of the box · no setup sending

See it
Sensible defaults for a brand-new account
Area
Integrations
Group
Provider architecture
System
Provider Independence
Solves
2 named problems
01The registry reads bindings; if none exist for that org and capability it maps the default chain to adapters.
02Email defaults to Mailgun first, then Resend.
03SMS defaults to Twilio only, so an unconfigured account fails honestly instead of trying a CRM sub-account it never connected.
A small table of capability → default chain, with voice showing an explicit 'none — must be configured' row. Sample data — no customer information appears here.
How it works
  1. 1The registry reads bindings; if none exist for that org and capability it maps the default chain to adapters.
  2. 2Email defaults to Mailgun first, then Resend.
  3. 3SMS defaults to Twilio only, so an unconfigured account fails honestly instead of trying a CRM sub-account it never connected.
  4. 4Voice has an empty chain on purpose, so an unconfigured tenant fails at configuration time with an honest message.
Why we built it

The comment names the exact failure mode of the old default: 'It used to lead with GoHighLevel, which was wrong in a way that only showed up at scale: an org that missed its seed (the creation paths swallowed that failure) would try GHL on every single send, against a sub-account it has never connected, and only reach working email after that attempt failed. Silent, slow, and the opposite of the policy.' Voice was worse: 'The old value was ["ghl"], which named a provider with no voice adapter — so the console asserted "calls ride GoHighLevel" while nothing could place or receive one through the port.'

The problem
  • A missed provisioning step made every send try a dead provider first.
  • The console claimed a voice provider that could not carry a call.
Sound familiar?
What you get
A brand-new or half-provisioned account still sends.
Errors name the real reason rather than an unrelated provider's rejection.

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 →