A new account is wired for sending the moment it exists

Every account-creation path seeds a full email chain on a neutral shared sending domain and provisions the builder's own Twilio subaccount at birth.

What it is

seedOrgCommsBindings writes Mailgun (priority 1, active, shared root), Resend (2), GoHighLevel (parked at 9, inactive) for email; GoHighLevel parked and Twilio seeded but inert (pending_setup) for SMS. It then calls provisionTwilioSubaccount so the builder's numbers, Messaging Service and A2P registration have somewhere isolated to live. Writes are insert-only so re-provisioning never clobbers a promoted custom domain or an operator edit.

Also called: onboarding provisioning · automatic email setup · shared sending domain

See it
A new account is wired for sending the moment it exists
Day rate
$600
Days figured
6
Crew size
5
Fuel & equipment
$300
Finished 2 days early — $1,800 back to the crew
An onboarding timeline: 'Account created' → five binding chips appearing → 'Twilio subaccount AC••••' — with the Twilio step marked optional/non-blocking. Sample data — no customer information appears here.
How it works
  1. 1Org is created (signup, funnel, or operator).
  2. 2The shared sending root and encrypted Mailgun key are read from the _platform binding, so moving future orgs to a different root is a pure config change.
  3. 3Five binding rows are upserted with ignoreDuplicates.
  4. 4A Twilio subaccount is created for the org, non-fatally — email works without it.
  5. 5The registry cache is invalidated.
Why we built it

Two reasons are recorded. First, reply capture: 'A tenant on our own sending domain has a reply path we control: mail.pfbuild.com has MX records and an inbound route, so a customer's reply is captured, stored and shown. On GoHighLevel the reply lands in GHL's inbox and the app only sees it while a tab is open.' Second, isolation at scale: the subaccount is 'Created at birth alongside the email chain, because the alternative is remembering to do it later for hundreds of accounts.' The file also records a deliberate non-migration — an existing tenant 'deliberately stays on GoHighLevel for both channels because that is where their established setup lives, and changing a working live account is a decision, not a default.'

The problem
  • Automations firing on a new account's first action had no provider to route through.
  • Replies to tenant mail landed somewhere the app could not read.
  • Twilio subaccounts had to be remembered manually per account.
Sound familiar?
What you get
First-day automations send correctly with zero setup.
Customer replies are captured from day one.
Re-running provisioning is safe and never overwrites custom settings.

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 →