Hosted answer pages

Hosted answer pages are a place for Attensira’s changes to go when your own site cannot take them: no repository we can open a pull request against, no CMS we can draft into. Each page answers one question your buyers ask AI engines, on a small site we serve for your workspace. You can serve that site from a subdomain you own, such as answers.yourcompany.com, by adding one DNS record. Nothing about a hosted page is hidden from you. It is a change like any other: drafted by an agent, approved by you or by the workspace’s autonomy level, listed in your history, and undone with one action.

​

Choosing hosted answer pages

Hosted answer pages are chosen where you choose any destination: the Connect step of setup, or PUT /v1/onboarding/workspace/{id}/destination with hosted. There is nothing to sign in to and no credentials change hands. Choosing it gives the workspace its site, at one subdomain of ours named after the workspace. We pick that address; it cannot be set to an arbitrary host. Names a reader would take for ours, such as www, api, app or docs, are never given out.

​

What a page contains

Every page is the answer, written for the question, and the parts an answer engine reads first:

• The answer itself, from the change you approved, written in Markdown and turned into HTML when the page is served. Raw HTML in the text is never passed through, so nothing an agent quoted can run as a script on a page under your name.
• A title, a description and a canonical address. The canonical address is your own subdomain once it is live, and our address before then.
• The date it was last updated, on the page and in the Last-Modified header.
• Questions and answers, when the change has them, shown under Questions on the page.
• Structured data (JSON-LD): an Article with your organisation as publisher and the date it was modified, and a FAQPage when the page has questions and answers.

Every claim on a page is held to the same rules as anything else an agent writes: it traces back to a Brand Book fact or a cited source. See Every claim traces to a fact or a source.

​

What the site serves besides the pages

Answer engines crawling these pages is the reason the site exists, so it allows them by design. Choosing hosted answer pages is agreeing to that. The site answers GET and HEAD only. When our store cannot answer, a request gets 503 with Retry-After: 60 rather than 404, so a crawler retries instead of dropping a page that is still there.

​

Publishing

A hosted page is an own-site change, so the own-site lane’s autonomy level decides whether it waits for you. At L3 and above it publishes after its 48-hour window unless you stop it; below L3 it waits in your Inbox for a yes. Once approved, a page is live the moment it is written. A new site starts serving within about 30 seconds. A page is never cached on our side, so an update or a removal shows on the next request.

​

When a page cannot be published

A publish that a retry would not fix is not published, and you get one Inbox row titled Couldn’t publish: with the page’s title, saying why and what to do: A store that briefly does not answer is retried automatically and files nothing.

​

Undo

Undoing the change that published a page takes it down:

• A new page answers 410 Gone for 30 days and leaves the sitemap and llms.txt, so search and answer engines drop it rather than retrying. After 30 days its address is a plain 404.
• An update to a page puts back exactly what the update replaced.

A page is taken down by undoing the change that published it, not by asking for a new change. If a later change edited the same page, undo that one first: an undo never overwrites a newer edit.

​

Serving from your own subdomain

By default the site is served at our address. To serve it from a host you own, connect a subdomain such as answers.yourcompany.com: It has to be a subdomain: a CNAME record cannot sit on a bare domain such as yourcompany.com. A host under one of our own domains cannot be used, and a host already connected to another workspace answers 409. A host another workspace had disconnected automatically is free: connecting it releases the old claim.

​

Where the domain stands

GET /v1/destination answers where the workspace’s changes go, with a domain block for the hosted site’s own domain, or null when there is none: While the host is anything other than live, the pages keep serving at our address, and our address stays their canonical one.

​

When the record is wrong

A host that breaks, or that is still waiting for its record a day after you connected it, becomes one Inbox row titled Fix the DNS record for your host. The row names the exact record to set. For a broken host it also asks you to check that no proxy or CDN sits in front of the record, and that any CAA record on your domain allows certificates for it. The check that finds the host live again closes the row by itself; the row is not repeated on every check.

​

When we disconnect a host

A host stays registered with us until something removes it. When the name no longer leads to your pages, we remove it ourselves, so a name pointed elsewhere is not left claimed by your workspace. We disconnect a host when:

• Its record points elsewhere for over an hour. This applies to a host that has been live: its CNAME no longer points at our host, and it has not served for more than an hour. The hour keeps a record you are editing in place from being taken for one you removed.
• The workspace no longer has hosted answer pages.
• The workspace was cancelled: the organisation or the workspace was deleted, or an organisation that had a plan has none now. A workspace that never had a plan, such as one set up before paying, is not cancelled. We check this at most once an hour for each host, and a check that fails to get an answer never disconnects a host.

The record and the hosted pages are checked every five minutes, with the other checks. A disconnected host has the status detached, and you get one Inbox row titled We disconnected with your host, saying why and naming the exact record. If the record points elsewhere, the row asks you to set it again with the value shown, or to remove the domain here if you moved the name on purpose. If the workspace has no hosted pages or was cancelled, the row asks you to remove the CNAME record at your DNS provider, so the name no longer points at pages you do not use. An open Fix the DNS record for row for the host is closed and replaced by this one. We do not check a detached host again on our own. To serve the pages there again, set the record and then POST /v1/destination/domain/check, or connect the same host again with PUT /v1/destination/domain. Either one connects the host again and checks it like a new one: it goes live by itself once the record is in place, and the We disconnected row closes. While the workspace stays cancelled, both answer 403: choose a plan for the workspace, then check the domain again. A detached host no longer holds its name. Another workspace that connects the same host takes it, and the detached claim is released.

​

Disconnecting

DELETE /v1/destination/domain stops serving the pages at your host. They keep serving at our address. To use a different host, remove the current one first: a workspace has one host at a time, and connecting a different one while one is connected answers 409. Connecting the same host again answers it as it stands, unless we disconnected it, in which case it connects again.

​

Keys and scopes

Connecting and disconnecting a host needs steer; a read-only key can read where it stands and ask for a check, never connect or disconnect. Connecting, checking and disconnecting charge nothing and work on a spent balance. On an organisation-wide credential, name the workspace with ?project=. See API authentication.