SMS Reminders — What You Need To Do

1. Twilio Console → Account → API keys & tokens → Auth Tokens
2. Request a secondary token
3. Update anywhere the old token is used, then Promote the secondary to primary — the old one dies

→ API keys & tokens

Same page → Create API key → name it boom-sms → type Standard. Copy the SID (SK…) and Secret (shown once — save it now).

Console → account switcher (top-left) → View subaccounts. For the reseller model, create/keep one subaccount per client (each client gets its own subaccount).

• Easiest — register in your PAID account (Boom Media) as the reseller. You register the client as a business under Boom Media; you never touch the client's trial account. No upgrade of the client account needed.
• Or upgrade the client's own account off Trial ("Trial · Upgrade" → add a card) and register there — more isolation, but the client account then carries its own bill.

In Trust Hub → Registrations: a Campaign attaches to a Brand, and a Brand is built from a Business Profile. So an empty "A2P Campaigns" screen is normal — you need a Brand first. Order:

1. A2P BRANDS tab → register a Brand. It walks you through a Business Profile — for a client you resell for, create a Secondary Business Profile with the client's legal name, EIN, and address.
2. A2P CAMPAIGNS tab → Create A2P Campaign → select that Brand → transactional use case + sample texts (next steps below).

Console → Trust Hub → your Primary Business Profile → Business Identity → "ISV Reseller or Partner."

Trust Hub → A2P 10DLC → create a Secondary Customer Profile for the client → then a Brand (Standard / Low-Volume Standard, ~$4.50 one-time).

You'll need from the client — get it exactly right:

• Legal business name exactly as on the EIN letter (mismatch = the #1 rejection reason)
• EIN / Tax ID, registered business address, website URL, industry
• An authorized-rep name + email

Under the Brand → create a Campaign (~$15 one-time vetting + a small monthly). Pick the transactional use case — "Account Notification" or "Customer Care", not Marketing.

Campaign description (paste something like this):

Sample messages (must match what you'll really send — carriers compare):

Each client gets their own local number (~$1.15/mo) under their own Messaging Service — never shared. Two ways:

• Manual: Console → Messaging → Services → create one for the client → add a number (area code 561, SMS enabled). Attach the number to the Campaign.
• Via the rail (already coded): GET /api/sms/numbers?areaCode=561 searches available numbers (admin-guarded by CRON_SECRET). Record the MG… service SID + number on the client's sms_clients row.

Run Localey/supabase/002_sms_shared.sql once against the shared Supabase (Studio SQL editor). It creates sms_clients, sms_consent, sms_messages — no app prefix because they're ecosystem-shared.

One row in sms_clients per client, so the rail knows which number/brand to send from:

insert into sms_clients (client_id, display_name, twilio_subaccount_sid,
  messaging_service_sid, phone_number, brand_sid, campaign_sid, registration_status)
values ('<the client's tenant id>', 'Your Client Business Name',
  'AC…', 'MG…', '+1561…', 'BN…', 'CM…', 'approved');

In each app's environment (Vercel project settings — or Doppler, which you already provisioned and should finally wire):

TWILIO_ACCOUNT_SID=AC386411e7f0b20bb01989ca253da7f22b
TWILIO_API_KEY_SID=SK...          # from Phase 1
TWILIO_API_KEY_SECRET=...         # from Phase 1
TWILIO_AUTH_TOKEN=...             # the NEW rotated token (inbound webhook signature only)
TWILIO_FROM_NUMBER=+15617828290   # pilot fallback sender
SMS_WEBHOOK_BASE=https://dashee.online   # (or localey.online) — must match the webhook you set below
CRON_SECRET=...                   # already set; guards the numbers/dispatch routes

Deploy the app (Vercel, git push). Then on the client's Messaging Service → Integration:

• Inbound (a message comes in) → {SMS_WEBHOOK_BASE}/api/sms/inbound (POST)
• Status callback → {SMS_WEBHOOK_BASE}/api/sms/status

I'm building this into Dashee now: a contacts + consent capture screen where the client records each customer's mobile number with an SMS-consent checkbox (source, exact wording, timestamp) written to sms_consent via the existing POST /api/sms/consent.

For bail bonds the natural capture point is the indemnitor agreement / application at intake — add the consent line there and record it in Dashee.

Building now in Dashee: from a contact, the client picks a reminder type (court date / check-in / payment), fills the details, and sends now or schedules it. It calls the shared rail:

sendSms({ clientId, phone, body, app: 'dashee', kind: 'transactional' })

The rail handles E.164, STOP suppression, per-client sender routing, segment/cost counting, and the audit log automatically.

Opt your own number in, send yourself a reminder. Confirm it arrives, the row lands in sms_messages, then text STOP and confirm you flip to opted_out and the next send is blocked.

With the campaign approved, consent captured, and the STOP test green — turn it on for your client and send real court-date/check-in reminders. Watch sms_messages delivery statuses for the first batch.

Rewardee offers, BOO order status, Localey review asks all call the same sendSms() + shared ledger. First lock the canonical client_id mapping (flagged in the migration) so STOP suppresses across every app.

Move the inbound webhook into Replyee, add a thread model, point the RAG engine at inbound texts — "your texts answer themselves at 10pm." This is what justifies the higher tier.

Three tiers ($29/$59/$99) + metered overage. Build a self-serve 10DLC registration form once you have ~5 SMS clients — until then, register them by hand as above.