Preview, publish, restore, and add a domain

Publishing is an explicit promotion from editable portal state to an immutable build. This keeps client-facing documentation stable while your team continues editing the next version.

Understand the states

• Draft — the current editable portal and latest connected specs.
• Preview — a human check of what the next build will look like.
• Live — the immutable build currently served to clients.

A GitHub sync can update the latest spec without changing the live build. The portal becomes current only after you preview and publish again.

Preview before publishing

Review the portal as both a new client and an existing integrator:

• Follow the quickstart from an empty environment.
• Search for product terms, operation names, and common errors.
• Open every navigation group and external link.
• Check code wrapping and tables at mobile width.
• Verify public and authenticated pages in separate browser sessions.
• Confirm the spec revision and examples match the intended release.

Publish a build

Choose Publish from the portal builder. API Fleet renders the pages and assets, pins the connected spec revisions, creates a build record, and switches the portal's live build when successful.

Do not close the page or assume success while a build is still running. If it fails, the previous live build remains the safe version.

View and restore history

Open Settings → Publishing. The build list shows previous snapshots. To roll back, identify the correct build and choose Restore. The selected build starts serving immediately; history remains available.

Restoring a build does not undo current draft edits. You can fix the draft and publish a new build later.

Configure portal access

Open Settings → Access. Decide whether the live portal is public or requires authentication, then review any page-level gates. Use the least exposure that still serves the intended clients.

Before launch, test:

• Signed-out access to public pages.
• Signed-out denial for restricted pages.
• Signed-in access for the correct organization members.
• Direct URLs, not only navigation clicks.

Add a custom domain

1. Open Settings → Custom domain.
2. Enter a subdomain such as docs.company.com.
3. Add the ownership-verification DNS record shown by API Fleet.
4. Wait for API Fleet to mark the hostname verified.
5. Add the displayed CNAME at your DNS provider.
6. Wait for TLS to become ready, then test an HTTPS page and nested route.

Use a CNAME/DNS route, not a browser redirect. A redirect changes the visible hostname and can break nested paths; DNS lets API Fleet serve the complete portal securely on your hostname.

If you use Cloudflare DNS, create the exact record API Fleet displays. Start with proxying disabled if verification fails, then enable proxying only when the product's domain instructions explicitly support it.

Remove or replace a domain

Keep the API Fleet hostname available during a DNS transition. Remove the old custom hostname from API Fleet only after clients and links have moved. DNS and certificate caches can take time to expire.

Publish checklist

• [ ] The intended source commit and spec revision are attached.
• [ ] The quickstart succeeds with non-production credentials.
• [ ] Public and authenticated access was tested.
• [ ] Navigation, search, code copy, and external links work.
• [ ] Mobile layout is readable.
• [ ] Custom hostname and HTTPS work on more than the home page.
• [ ] The team knows which build to restore if needed.