Your hostname in front of an agent-built page

Add the hostname

curl -X POST https://read.botook.ai/custom-domains \
  -H "Authorization: Bearer otr_live_YOUR_KEY" \
  -H "content-type: application/json" \
  -d '{"hostname":"share.example.com","site_id":"SITE_ID"}'

The reply includes the two records to create: a CNAME for routing and a TXT for ownership.

Create the records

Any DNS provider will do — this does not require your zone to be on Cloudflare, though it happens to be Cloudflare doing the serving on this deployment.

Verify

curl -X POST https://read.botook.ai/custom-domains/share.example.com/verify \
  -H "Authorization: Bearer otr_live_YOUR_KEY"

Verification actually resolves the records. A hostname whose DNS is not in place is refused — an optimistic "verified" that later serves nothing is worse than a clear failure, so this reports what it found instead.

What lands on it

Bind a hostname to one site and its root becomes that page. The unlisted token keeps working in parallel, so a link already in someone's inbox does not break the day you add a domain.

Listing and removing

curl https://read.botook.ai/custom-domains -H "Authorization: Bearer otr_live_YOUR_KEY"

Remove one and traffic falls back to the token URL. Nothing about the content changes.

Certificates

Issued automatically once verification passes; renewal is not your problem. Until the certificate is live the hostname does not serve — no window where a client meets a warning page.

Why bother

• A deliverable on your own domain reads as your work, not as a link to a service the client has never heard of.
• Some corporate networks are friendlier to a known hostname than to an unfamiliar one.
• It survives you changing where the page is hosted later.

What it does not do

It does not make the page public. Gates and expiry apply exactly the same on a custom hostname — password, work-email gate, burn-after-read, scheduled deletion.

A domain for each client

Nothing stops you adding many. Reports for one client on one hostname, another elsewhere, and each with its own pages behind it.

Agent-built pages, human-looking addresses

This is the piece that makes agent output presentable. Claude or Codex or ChatGPT writes the page and publishes it in a loop; the client sees a hostname they recognise. Nobody outside has to know the page was assembled by a model twelve minutes ago.

Compared with a general host

What the address looks like afterwards

A verified hostname bound to a page serves that page at its root. There is no token in the path and nothing for the reader to interpret — reports.yourfirm.com is the document, not a directory containing it. That is a deliberate one-hostname-to-one-page mapping rather than a second way to browse your account:

Both addresses stay live, which matters when you move a page onto a domain after the link is already out: nothing you sent last week breaks. Every gate, counter and expiry belongs to the page, so a password set before the move is still in front of it after.

Troubleshooting

Questions

How many domains?

Unlimited on this deployment — see pricing.

Apex domain or subdomain?

A subdomain is the clean path; an apex needs a provider that flattens CNAMEs.

Does it break my existing links?

No. Token URLs keep resolving.

Keep reading