The job
“Our users should walk away with a page that exists at an address. Not a draft, not a ZIP file, not a task for someone on our side.”
Generating HTML is the easy part of that promise, and it is the part most “AI website” features stop at. The rest is plumbing: a bucket has to exist, hosting has to be switched on, files have to land, a certificate has to be issued, DNS has to point somewhere — and somebody has to own the failure when step three works and step four doesn’t. Building that once, for your own product, is a quarter of engineering that has nothing to do with why your customers pay you.
What your product calls
One dispatch, from a description to a working address:
The designer turns the description into the actual page. The publisher does the unglamorous half. What comes back is the URL, plus the ordinary record of how the run got there.
Everything after the first call is also an endpoint: list the revisions of a site, roll back to a specific one, delete it. Undo is part of the integration, not part of your support process.
Why the tenancy shape matters to you
Your organisation is the tenant. You issue your own API token from your own settings page — nobody mints one for you, and nobody has to be in the loop when you rotate it.
Cloud credentials are stored against your organisation and resolved server-side by name at the moment a tool runs. That has a specific consequence worth stating plainly: there is no credential on our side that can reach another partner’s infrastructure, because the resolution is scoped before the tool ever executes. A read for an organisation that is not yours returns not found rather than forbidden — we do not confirm that the other tenant exists.
The one rule that matters operationally: the token is yours, and it stays server-side. It authorises everything your organisation can do, so it belongs in your backend, never in a browser and never in the hands of an end user.
Honest state
Running in production. A partner product dispatches this today with its own token against its own cloud account, and their customers’ sites are live. The path from brief to a working HTTPS address — generation, bucket, hosting, upload, CDN, certificate, DNS — is shipped, and so are listing revisions, rolling back to one, and deleting a site.
The live smokes are where it got real. They caught four defects that unit tests could not have: a cloud API that demanded a different content type, a tool registered on one execution path but not the other, three missing IAM grants, and an enum that had to be uppercase. A green build is not a working pipeline, which is why nothing here is called done before it has run against the real thing.
Where it is still narrow, and we would rather you heard it from us: the shipped adapter targets one cloud’s object storage, CDN and DNS — the workflow shape is not specific to it, but the other adapters are not written yet. Very large multi-file bundles hit a request-size ceiling we have not lifted. Certificate propagation at a cloud’s edge can take hours on a fresh domain; that one is theirs rather than ours, but it is real and worth planning into your onboarding. And the hostname your sites land on is a conversation to have before you start, not a setting you can flip on your own yet.