Your privacy policy and terms, generated and hosted

The platform generates a compliant privacy policy and terms page for each builder from details they already entered, and serves them publicly on their own address for carrier registration.

What it is

Two public pages per account, generated from the account's own settings — trading name, legal entity, address, phone, email, website, brand colour and logo — and served at <slug>/policies/privacy and /policies/terms with no login wall. Those URLs are what the account's messaging-campaign registration submits. A builder who already has compliant pages of their own can file those instead, but only as a matched HTTPS pair.

Also called: A2P policy URL · privacy policy for texting · terms and conditions url · 10DLC compliance pages

See it
Your privacy policy and terms, generated and hosted
Day rate
$400
Days figured
11
Crew size
5
Fuel & equipment
$300
Finished 2 days early — $1,600 back to the crew
The generated privacy page on a tenant subdomain, carrying the builder's logo and brand colour, with the URL bar showing their own address. src/app/policies. Sample data — no customer information appears here.
How it works
  1. 1tenantFromHost() resolves the account from the subdomain alone, deliberately independent of auth so the page is identical for an anonymous crawler and a signed-in user.
  2. 2Content is composed from the account's settings, with a specific fallback order for name, phone, email and brand colour.
  3. 3tenantPolicyUrls() builds the public URLs, deriving the host from the canonical site URL first and only then from the root-domain setting.
  4. 4policyUrlsForOrg() decides which URLs a given account submits — the platform's own legal pages for itself, the builder's own pair when both are HTTPS, otherwise the generated pages.
  5. 5A tenant's own URLs are stored and submitted exactly as entered, trailing slash included.
  6. 6Required phrases are exported as constants so a preflight check can assert they are still present before a campaign is filed.
Why we built it

The header explains why the platform took this on rather than asking builders to do it: carrier registration 'requires a PrivacyPolicyUrl and a TermsAndConditionsUrl that are publicly reachable, not behind a login, and relevant to the registered brand… Twilio publishes none of that as a spec you can hand to a customer — we learned every rule of it by having the platform's own campaign rejected.' The conclusion is stated plainly: 'Telling a post-frame builder with a Wix site add these clauses to your privacy policy produces a half-done page and a burned $4.50 brand fee. So we don't ask.' The host-derivation order carries its own incident: a stale root-domain setting 'would be filed with the carriers as the address of a business's privacy policy', and a local override 'did exactly that during development and produced an unreachable URL.' The trailing-slash rule is a rejection code: some sites redirect the policy path, 'and a vetter that doesn't follow redirects records a non-200 and fails the URL.'

The problem
  • Carrier registration requires legal pages most small builders don't have.
  • A half-written policy page burns a non-refundable registration fee.
  • A stale environment setting could file an unreachable URL with the carriers.
Sound familiar?
What you get
The hardest part of messaging registration becomes a form you already filled in.
The pages are hosted on your own address and reachable without a login.
If you already have compliant pages, yours are filed instead — exactly as entered.

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 →