Custom domain API
A REST API that lets a SaaS product accept and serve traffic on customer-owned hostnames, including TLS, routing, and DNS monitoring.
A custom domain API is a service-as-a-service: instead of building your own pipeline for issuing certificates, attaching them to a load balancer, and routing traffic by Host header, you POST a hostname to an API and the provider handles all of it.
What it does (the four pieces)
- TLS issuance. You provide a hostname; the API talks to a certificate authority (typically Let's Encrypt via ACME) and provisions a cert. Re-renewal is automatic.
- Edge routing. Customer traffic hits the API's edge servers, not yours. The edge proxies the request to your origin, preserving or rewriting the Host header depending on your preference.
- DNS monitoring. The API checks whether the customer's CNAME still resolves correctly and surfaces "domain verified / failed / expired" status to you.
- Webhook events. When DNS lands or breaks, the API fires a signed webhook so your app can react (mark the domain green, email the customer).
How it differs from adjacent things
- Not a domain registrar. Doesn't sell the customer the domain. Customer brings a domain they already own.
- Not a DNS host. Doesn't host the customer's full DNS zone. Customer keeps DNS at GoDaddy / Namecheap / Cloudflare and just points one CNAME.
- Not a CDN. Doesn't cache content (usually). It's a thin transparent proxy with TLS termination.
Why teams adopt one
Building it yourself: 4–8 engineering weeks for a working v1, plus ongoing maintenance of Let's Encrypt rate limits, certificate renewal cron, DNS health checks, and the SSL state machine.
Adopting a custom-domain API: a few hours of integration, plus a recurring per-domain bill.
The math usually flips toward "adopt" once you have more than ~50 active custom domains, because that's roughly when the maintenance load eats more than 5 hours of engineering time per week.