# Optiview Customer Onboarding & Technical Integration Guide

Last reviewed: October 4, 2026. Private beta.

Canonical guide: https://optiview.ai/onboarding/

<a id="start"></a>

## 1. Start here: scope and first successful delivery

This is the customer implementation guide for Optiview’s private beta. It covers account access, ownership verification, source acquisition, reviewed brand content, publication, delivery integrations, and ongoing operations. It is intended for agency administrators, marketing strategists, web developers, and security reviewers. Last reviewed: October 3, 2026.

Optiview extracts readable website content, converts it into Markdown, and combines it with your published structured brand definitions and content blocks. The dashboard manages those additions; an edge route or your server delivers the resulting payload. Optiview does not replace your CMS, make a blocked origin universally accessible, or establish that an AI service indexed or used a response.

1. Choose one public hostname and one representative page. Record the source facts you expect to retain, including prices, variants, eligibility conditions, and footnotes.
2. Get workspace access, add the exact hostname, and verify ownership using one of the three supported methods.
3. Choose a delegated Cloudflare route or a server-side Enterprise API integration. Protected origins can supply HTML directly.
4. Save approved Brand Details and Added Content with the appropriate page paths. Review the saved draft and publish it.
5. Fetch the published payload, inspect its content and publication version, test failure behavior, and then enable delivery for your approved public paths.

Start with a limited page allowlist before expanding. The first milestone is a reproducible, accurate payload and safe fallback—not a successful response for every URL on the internet. Use the [acceptance checklist](#acceptance) before enabling customer traffic.

<a id="concepts"></a>

## 2. How the platform fits together

| Component | Purpose |
| --- | --- |
| Workspace | An agency or customer tenant containing members, domains, drafts, and usage. |
| Domain | One exact hostname, such as www.your-domain.com. Its ownership, keys, settings, and publications are scoped separately. |
| Source | Public HTML fetched by Optiview, optionally browser-rendered, or HTML supplied by your server. |
| Parser | Removes interface clutter, preserves supported content structures, cleans links, and identifies some incomplete or error responses. |
| Approved brand content | Your structured brand details and approved Markdown content blocks. Publishing them does not control an AI model’s answers. |
| Draft | Editable, saved configuration. Saving does not publish it. |
| Publication | A saved snapshot used for delivery, with a version and optional exact-path override. |
| Delivery | A proxy response or an Enterprise API response. It is not evidence of indexing, citation, or verified crawler identity. |

```
Source HTML → semantic extraction → Markdown
                                      + published, path-matching brand content
                                      → payload + publication version
                                      → edge response or your server/CDN
```

There are three different previews: the public Website Preview generates labeled, unreviewed examples; dashboard Content Preview uses a saved draft; the Render API and connected edge use published content. These results can legitimately differ. Use the delivery channel you intend to deploy for final acceptance.

<a id="access"></a>

## 3. Account access, roles, and responsibilities

Access is provisioned for the private beta. [Request a pilot](https://optiview.ai/#beta) if your organization does not yet have a workspace. Submitting the interest form saves your request and alerts hello@optiview.ai. It does not automatically create an account, issue a key, or activate billing. Sign in at [app.optiview.ai](https://app.optiview.ai) using your email and private access key. Store access credentials in your password manager; do not share them in integration code.

| Role | Scope | Capabilities |
| --- | --- | --- |
| Agency admin | All workspace domains | Add and verify domains; manage connection settings, credentials, team access, drafts, publishing, and cost assumptions. |
| Strategist | Assigned domains only | Review source content, edit and save brand content, preview, and publish. Cannot manage routing, API credentials, or team access. |
| Viewer | All workspace domains | Read-only access. Do not assign this role when access must be restricted to one client domain. |

An admin uses the team area to create an invitation link, choose the role, and assign domains for a strategist. Invitations expire after seven days and are single-use. Share the link privately with the invited person. Admins can revoke invitations and member access. Dashboard sessions expire; signing in again is separate from rotating a domain API key.

- Business owner: approves factual claims and the scope of publication.
- Strategist: maps content to paths and reviews draft/output accuracy.
- Web or CDN engineer: integrates delivery, secrets, fallback, and cache behavior.
- Security owner: approves source access, public-page exclusions, and any narrowly scoped security changes.
- Workspace admin: owns credentials, domain configuration, access reviews, and escalation.

<a id="inventory"></a>

## 4. Prepare the site and choose the hostname

- Identify the canonical HTTPS hostname. www.your-domain.com and your-domain.com are different domains for verification and API access. Choose the hostname that serves the final page without a redirect.
- Inventory page types: homepage, category, product, pricing, documentation, article, and policy pages. Include JavaScript-heavy pages, tables, variants, and legal qualifications.
- Identify your CMS, hosting provider, CDN, existing Worker/middleware, and the team that controls them. A CMS theme editor alone may be insufficient for server-side integration.
- Decide which pages are public and nonpersonalized. Exclude accounts, checkout, admin, authenticated content, private previews, and pages containing personal information.
- Choose a content approver, integration owner, and rollback owner. Keep a record of the current origin and routing configuration.
- Determine whether initial HTML contains the content. If JavaScript is necessary, assess browser rendering or server-supplied, already-rendered HTML.

Add a hostname, not an individual URL. Once a domain exists, target individual URLs through page paths in brand rules, Content Preview, publications, and Render API requests. Do not create a separate domain for each product page.

<a id="verify"></a>

## 5. Add a domain and verify ownership

1. In the workspace overview, select **Add domain**. Enter the ASCII hostname only: no https:// prefix, path, port, or wildcard.
2. Use the generated ownership challenge. Select DNS TXT, HTML Meta Tag, or File Upload (.well-known). Copy the values exactly from the dashboard.
3. Install one proof, then click **Verify Ownership**. A challenge expires after seven days; checks are limited to one every 15 seconds.
4. After verification, open **Website Setup → Connection**. Keep the proof in place: connection and provisioning operations may check it again.

### Option A — DNS TXT

Create a TXT record at the displayed name, normally `_optiview.www.your-domain.com` for `www.your-domain.com`. The value begins with `optiview-verification=` and contains a unique challenge. DNS consoles may automatically append the zone name; avoid entering it twice. This is a proof record, not a traffic-routing record. Allow DNS propagation and check the exact hostname.

### Option B — homepage meta tag

```
<meta name="optiview-verification" content="COPY_THE_ENTIRE_DASHBOARD_VALUE" />
```

Place exactly one matching tag in the homepage’s server-rendered HTML `<head>`. The verifier fetches `https://YOUR_HOSTNAME/` and requires a direct 200 HTML response. It does not execute JavaScript or follow redirects. Inspect the initial HTML, not only the browser’s live DOM. A tag inserted after hydration will not verify.

### Option C — public text file

```
https://YOUR_HOSTNAME/.well-known/optiview-verification.txt

File contents: the entire TXT record value shown in the dashboard
```

Serve the exact value as a public text file over HTTPS with a direct 200 response. The path is `optiview-verification.txt`, not `optiview.txt`. Do not wrap the value in HTML. HTTP proof requires a public DNS resolution and a valid HTTPS endpoint. A redirect from apex to www means you should register and verify www instead.

A hostname already registered to another workspace cannot be claimed again. Ask the workspace operator to reconcile an authorized transfer. Successful verification proves control; it does not change DNS, create a route, bypass a firewall, or publish content.

<a id="choose"></a>

## 6. Choose a delivery integration

| Path | Use when | Customer work |
| --- | --- | --- |
| Delegated Cloudflare route | Your proxied hostname belongs to the Cloudflare account delegated to the workspace. | Admin connects the route; technical owner checks origin health, overlapping routes, and security. |
| Enterprise API: URL fetch | Your server/CDN can call Optiview and the origin exposes public, cookie-free HTML. | Verify domain, create key, publish, add a server-side adapter with fallback. |
| Enterprise API: supplied HTML | The origin is protected or your own application can provide the approved source. | Your server sends public HTML; supply already-rendered HTML when JavaScript is required. |
| External Cloudflare for SaaS | An operator is planning a custom-hostname migration. | Certificate provisioning is only a preparatory step. Origin forwarding and approved cutover are still required. |

For API integration, DNS can stay as it is. You still need engineering access to a server or CDN that can call the API and deliver the response. An API key or ownership meta tag alone does not place Optiview into the request path. Do not make a CNAME change merely because a certificate becomes active.

<a id="edge"></a>

## 7. Connect a delegated Cloudflare route

1. Confirm the exact hostname is verified, its existing A/AAAA/CNAME record is proxied through Cloudflare, and the zone belongs to the configured delegated account.
2. Have the workspace operator provision scoped routing access. Customers do not paste Cloudflare tokens into page content or the browser.
3. Check for overlapping Worker routes and confirm the origin is healthy. Resolve conflicts with the route owner before changing routing.
4. Open **Website Setup → Connection** and click **Connect Route**. The operation creates or reconciles the hostname/* Worker route. It does not change DNS records or security rules.
5. Publish approved content and run the HTML/Markdown checks in this guide. Inspect real origin behavior and security logs before expanding the rollout.

A verified domain in a different Cloudflare account is not automatically eligible. “No delegated account,” “No active delegated zone,” or “routing not configured” requires operator setup or an Enterprise API integration. Do not broaden token access just to suppress a connection error.

Use **Disconnect Route** to remove the managed route while retaining drafts. If route ownership changed or cleanup failed, stop and ask the operator to reconcile it. Do not delete unrelated Workers or routes. Retest ordinary HTML after disconnecting.

<a id="api"></a>

## 8. Enterprise Render API: credentials and contract

An admin opens **Website Setup → Connection → Enterprise API** on a verified client domain and generates a domain-scoped key. Copy it once into a server secret manager. Render keys start with `ov_live_`; only a cryptographic hash is stored. Rotation replaces the previous key, and revocation invalidates it. Coordinate credential changes with your adapter to avoid fallback-only traffic.

The endpoint is `POST https://app.optiview.ai/api/v1/render`. It is a server-to-server API; browser Origin requests are rejected and CORS is not enabled. Never use a NEXT_PUBLIC environment variable, frontend bundle, Shopify theme, or browser local storage for the key. A dashboard login key and a partner integration key cannot replace a Render API key.

| Request field | Rules |
| --- | --- |
| url | Required HTTPS URL, at most 2,048 characters, with the exact hostname associated with the key. No credentials, explicit port, or fragment. Use a canonical public path. |
| html | Optional. When present, must be a nonempty string no larger than 2,000,000 UTF-8 bytes. Empty or invalid HTML is rejected; it does not fall back to fetching. |
| include_evidence | Optional boolean. Set true only with supplied HTML to request sampled source-evidence diagnostics. Unsupported in URL-fetch mode. |
| JSON body | Under 3,000,000 bytes, with Content-Type: application/json. |
| Authorization | Bearer token in the Authorization header. Do not forward it to the source site. |

Optional discovery: add include_discovery: true to a supplied-HTML request. The separate discovery object preserves observed navigation, footer and content links, plus supported source-declared JSON-LD and microdata commerce entities and explicit relationships. Fields include source selectors or JSON pointers and the source hash. The profile reports page-type evidence without changing pruning. Reconciliation exposes agreement, conflicts and missing declarations. Visible evidence separately checks explicitly labeled SKU and price text in an identifiable product region; it does not establish live visibility, freshness or policy applicability. Visible role_observations preserve supported source labels separately: SKU, product code, item number, starting price, current bid and shipping price are not interchangeable. Generic price/code labels remain unknown roles; unresolved product attribution has no product references. Discovery relationships also preserve supported quantity/unit-price rows and explicit plan-card rates, allowances, overages and billing qualifications with source selectors. Product identity remains unresolved without matching item evidence. Currency symbols, rate cadence and CSS conditions do not establish an ISO currency, contract term or active offer. Unsupported layouts are not reconstructed. The variants view preserves explicit ProductGroup membership and same-product Offer URL variant parameters with offer-local identifiers and prices. Parent SKUs and family prices are not inherited; DOM option labels require a unique matching variant marker. Unresolved references remain unresolved; selection and inventory are not verified. These declarations are unverified and are not appended to the published Markdown. No target pages are fetched, and a policy link does not establish that its terms apply to a product. Limits and truncation are reported. URL-fetch requests do not support this option. The tokens field continues to count the Markdown payload only.

Pricing source evidence: relationships.plans.groups preserves supported explicit or repeated rate-and-signup plan containers. Streamed plan records identify their source boundary/segment and label reconstructed-DOM selectors; JavaScript is not executed. Recovery supports bounded standalone completion calls and an exact fingerprint of a reviewed runtime; unknown variants remain unsupported. Pricing-feature icons with explicit text labels retain those labels. Unlabeled or conflicting icons are marked unresolved, not assumed to mean included. Structured plan feature_states carry the same distinction. Storage allowances and explicit overage thresholds remain source observations. Minimum usage commitments and included usage credits are separate records; a credit period does not establish the commitment billing period. Supported inline or immediately preceding From/Starting at labels are retained as lower-bound rate evidence. Other qualifiers may remain only in the local source text; do not treat a recognized rate as a complete invoice. Page currency statements are separate notes, not inferred currency assignments. relationships.addons keeps explicitly labeled add-ons separate from base plans. relationships.plans.free_tiers retains local Free-label, usage-limit and signup context; conditions elsewhere may be missing. comparison_columns preserves supported named rate-bearing table headers and unmerged same-table rows. Separate tables are not joined by visual order, icon-only cells are not interpreted, and dynamic expressions remain unevaluated. These beta views are bounded and incomplete; review qualifiers, truncation and source references before use. Content Preview displays the additional evidence without approving or publishing it. Supported pricing records distinguish per-seat or per-developer rates, hourly rates, monthly caps, starting prices and minimum commitments. Paragraph-named repeated offer lists carry explicit name provenance. Add-on rates can retain per-dataset units and their source eligibility section. relationships.summaries contains corroborated priced entity summaries, such as deployment options, without classifying them as subscriptions. Source context and the dashboard preserve their full descriptions. Named plan components retain their own rates and source units in components.groups; multiple source prices remain source_alternatives_unresolved rather than selecting a billing state or summing an invoice. An explicit + usage suffix remains a usage_qualifier, not a computed charge. Explicit Support sections may yield priced_service_tier summaries with the support tier, rate and full local description; these are not base subscription or compute rates. Repeated offer containers and heading groups are supported only when local name, rate and action evidence meet the bounded rules. A price heading can be paired with its immediately adjacent unit region when the bounded structure is unambiguous; amount_evidence and unit_evidence retain separate source references. Billing, savings and trial labels remain source conditions. Repeated plan names and CSS-hidden or invisible states do not establish distinct products or an active billing choice. Subordinate feature headings are accepted only with local list/table structure and without a separate commercial offer. These are bounded source observations; responsive billing choices, inferred invoices and eligibility decisions are not resolved.

Optional source selection (beta): add source_query, a non-empty string of at most 500 characters, to a supplied-HTML request. The separate source_context object selects bounded, complete supported variant, quantity-price and plan records, or unfetched discovery links. It includes the source SHA-256, selectors, qualifiers, omitted-match counts and unresolved identifier hints. Selection is lexical source evidence, not a generated answer, exhaustive retrieval, verified policy or publication approval. Unknown or ambiguous queries may return no match. Link-only selections use discovery_links_only and source_record_matches: 0; they do not establish facts about the destination. This option does not change the published Markdown, make external fetches or call an AI model. Existing domain-key authorization, billing and request limits apply. URL-fetch mode does not support source_query.

### URL-fetch request

```
curl --fail-with-body https://app.optiview.ai/api/v1/render \
  -H "Authorization: Bearer $OPTIVIEW_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{"url":"https://www.your-domain.com/product/"}' \
  -o render-response.json
```

Replace the hostname/path with your verified site and set OPTIVIEW_API_KEY securely in your server environment. URL mode does not forward your credentials or cookies. The origin must return public HTML directly, without a redirect or private/cookie-dependent response. Domain JavaScript rendering settings apply to URL mode.

### Successful response fields

| Field | Meaning |
| --- | --- |
| success / content_type | Success flag and text/markdown payload type. The HTTP API response itself is JSON. |
| payload | The complete Markdown string, including metadata and path-matching published curation. |
| payload_sha256 | SHA-256 of the UTF-8 payload bytes. Integrity check, not a signature or proof of consumption. |
| publication_version | Version of the published snapshot selected for this path. Record it with your acceptance evidence. |
| source_mode | url_fetch or supplied_html. Browser use is described in payload metadata. |
| cache_status | HIT, MISS, or BYPASS. Supplied HTML bypasses the conversion cache. |
| tokens | Estimated output tokens, not a precise tokenizer result or provider billing invoice. |

```
# Inspect the published Markdown (jq required).
jq -r '.payload' render-response.json > published-payload.md
jq '{success, source_mode, publication_version, cache_status, tokens, payload_sha256}' render-response.json
```

For supplied HTML, include_evidence: true adds extraction_report with a SHA-256 of the input HTML, a rule-based page type, and up to 80 source excerpts and relative selectors. Retained flags compare source text with extraction before approved additions are appended. The sample is bounded and can miss content or differ due to formatting; it is not a completeness score, confidence probability, or independent fact verification. URL-fetch mode does not currently support this option.

<a id="push"></a>

## 9. Authenticated HTML ingestion: protected origins

In supplied-HTML mode, your authorized server obtains the source and sends it to Optiview. Optiview skips external origin fetching and browser rendering, then runs extraction and appends the published, path-matching content. The URL identifies the verified hostname and publication path; it is not fetched in this mode.

1. Generate a public, nonpersonalized HTML representation inside infrastructure you control. Remove user data, session identifiers, access tokens, and private content.
2. If the page depends on JavaScript, render it on your side before submission. Optiview does not execute scripts in supplied HTML or fetch its embedded URLs.
3. Serialize the HTML with a JSON encoder rather than shell string interpolation. Submit the same canonical URL that your delivery adapter will serve.
4. Inspect the response, retained source facts, publication version, and any partial-content warnings. Keep serving your original page if conversion fails.

```
# public-page.html must contain authorized, nonpersonalized HTML.
# jq safely encodes quotes and newlines.
jq -n --arg url 'https://www.your-domain.com/product/' \
  --rawfile html public-page.html '{url: $url, html: $html}' > render-request.json

curl --fail-with-body https://app.optiview.ai/api/v1/render \
  -H "Authorization: Bearer $OPTIVIEW_API_KEY" \
  -H 'Content-Type: application/json' \
  --data-binary @render-request.json \
  -o render-response.json
```

This avoids external fetch restrictions; it does not guarantee extraction success. Error pages, empty shells, unsupported content, oversized bodies, and malformed input can still fail. Supplied HTML is a source for that render request; it does not update your CMS, save a dashboard draft, or publish new brand claims. Do not submit a logged-in customer page as a demonstration.

<a id="adapter"></a>

## 10. Deliver through your own server or CDN

Use the [Developer Hub adapters](https://optiview.ai/docs/) as starting points, then adapt them to your runtime and origin routing. The API returns a JSON envelope; your adapter sends the `payload` string as `text/markdown; charset=utf-8` only for eligible requests. Normal visitors should continue receiving the existing HTML response.

- Allowlist public hostnames and paths. Require GET and bypass requests carrying cookies, Authorization, or the X-Optiview-Fetch loop marker. Preserve your existing authentication and security controls.
- Use explicit Accept: text/markdown negotiation, honoring quality values. A User-Agent name such as GPTBot is not sufficient and does not establish bot identity.
- Set a finite API timeout appropriate to your latency budget. On a non-success status, invalid response, timeout, or unavailable service, serve the original response. Test this path deliberately.
- Keep HTML and Markdown cache variants separate. Return Vary: Accept and start with no-store until you have validated cache isolation. If caching API output yourself, include hostname, path, publication version, and representation in the design.
- Dashboard publishing changes Optiview’s cache version. It does not purge a separate cache in your CDN. Your integration must refresh or expire that cache.
- Avoid recursive origin routing. Optiview URL fetches carry X-Optiview-Fetch: 1; your adapter should bypass optimization for that marker and reach the origin.
- Do not send API keys in URLs, client-side code, analytics, or logs. Log safe status, timing, path, and version metadata instead.

Shopify theme.liquid can host an ownership meta tag, but cannot safely store a server secret or implement response interception. Shopify integrations need a supported server/CDN design. A static Next.js export cannot execute middleware; use its host’s server functions or another controlled delivery layer. CloudFront and other CDNs require runtime-specific adapters and secret handling.

<a id="source-settings"></a>

## 11. Source extraction and JavaScript settings

Open **Website Setup → Advanced Settings** to review the main content selector and additional frontmatter. The generated domain configuration starts with `main, article, .content`; extraction also has fallback behavior. Test your selector on each page type. A selector that targets only a description can omit prices, product variants, taxonomy, or qualifications elsewhere on the page.

The parser removes navigation and interface clutter while attempting to preserve meaningful in-body content, links, tables, and labels. It cannot recover facts absent from the source. Do not judge quality by token reduction alone: compare retained names, prices, units, conditions, citations, and product destinations with the source.

In **Connection → Tech Stack Configuration**, an admin can enable **JavaScript Prerendering (For React/SPAs)**. This setting is stored independently of the draft and changes rendering/cache behavior immediately. Public rendered pages can be cached for up to 15 minutes; publication and rendering-setting changes invalidate the relevant Optiview cache version. Browser work consumes a separate budget.

Browser rendering is bounded and restricts resources. Cross-origin dependencies, login flows, challenges, canvas content, and some component architectures may remain incomplete. Rendering is not a WAF bypass. For controlled applications, supplying already-rendered HTML can be a better integration than depending on an external browser.

<a id="curation"></a>

## 12. Brand Content: structured definitions and added answers

### Brand Details

Open **Brand Content → Brand Details** and add a schema. The form builder supports Organization, Product, and FAQPage. Choose a Page path before filling the fields. The form compiles JSON-LD; customers do not need to hand-edit JSON.

| Type | Fields and use |
| --- | --- |
| Organization | Company name, URL, description; optional core claims and logo URL. Use factual organizational information. |
| Product | Product name, URL, description; optional core claims, brand, price, and three-letter currency. Price must be nonnegative. Avoid global prices for products with different variants. |
| FAQPage | One to 40 questions and answers. Use approved, source-supported answers. |

Core claims are entered one per line. A domain supports up to 30 schemas and 30 content blocks. The current form is not a general-purpose multi-entity graph editor: do not paste an arbitrary @graph or assume Book/SoftwareApplication templates exist.

### Added Content

Open **Brand Content → Added Content**. Choose the page path, content type, and placement before or after page content. Supported types are FAQ_BLOCK, SITELINK_BLOCK, and COMPETITOR_TABLE. The body accepts Markdown, up to 50,000 characters per block. Use headings, lists, or tables when they improve clarity; ordinary short paragraphs are fine.

Use FAQ_BLOCK for questions and answers, SITELINK_BLOCK for curated destinations, and COMPETITOR_TABLE for supported comparisons. The category does not verify a claim. Do not invent certifications, testimonials, guarantees, warranty terms, or comparative superiority. Maintain an approval owner and source evidence for every material claim.

### Path targeting

| Rule | Effect |
| --- | --- |
| / | Homepage only. |
| /product/example | That exact path. Match the site’s trailing-slash convention. |
| /collections/* | Paths beginning with /collections/. Does not mean every product on the site. |
| /* | All paths in this hostname. Use only for genuinely global content. |

Rules can overlap; check that global and page-specific blocks do not repeat or contradict each other. Content rules may use section wildcards, while publication scope supports only all pages or one exact path.

<a id="page-guide"></a>

## 13. Page Guide (llms.txt) and frontmatter

Open **Website Setup → Page Guide (llms.txt)** to author a plain-text/Markdown roadmap to important public pages. Include accurate titles, URLs, and short descriptions. Save and publish it with the all-pages release when updating the domain-wide guide. On a connected edge route, `/llms.txt` is served as plain text, separately from page conversion.

```
# Your organization
> A factual one-sentence description.

## Public resources
- [Product](https://www.your-domain.com/product/): Approved product information.
- [Documentation](https://www.your-domain.com/docs/): Technical integration details.
- [Policies](https://www.your-domain.com/policies/): Published policies and conditions.
```

An API-only integration does not automatically create a public /llms.txt endpoint on your site. Your team must serve it through its own infrastructure if desired. The file is a guide, not an enforceable instruction to crawlers or a replacement for robots.txt.

Advanced frontmatter is structured metadata saved with the draft. Keep JSON syntax valid in the editor and review the resulting YAML header. Engine-owned delivery fields describe actual behavior; do not use custom metadata to imply verified ingestion or claim a capability that was not used.

<a id="publish"></a>

## 14. Save, review, preview, and publish

1. Complete edits and click **Save changes**. The unsaved indicator applies to the domain draft across tabs. Confirm it clears and note the draft version.
2. Open **Content Preview**, enter an exact Page path such as `/`, and run the preview. Preview uses the saved draft, not unsaved form text.
3. Check the main content, headings, product facts, links, table labels, price footnotes, schema, and all matching added blocks. Resolve partial-content warnings before approving the page.
4. Select publication scope: `/*` for all pages or a single exact path such as `/product/`. Click **Publish updates**.
5. Fetch through the deployed edge or Render API, record publication_version and payload_sha256 when available, and compare the delivered content with your approval.

Current dashboard Content Preview requires an active connected domain for client-site fetching. An API-only domain may show “Connect this domain before previewing.” Do not change DNS just to unlock preview. Use a designated test hostname/workspace and the Render API with a published, reviewed test snapshot; coordinate a staged release with your operator when production changes require prepublication source testing.

Saving increments the draft version. If someone else saves or a partner submits a suggestion, stale saves and publications can return a conflict. Reload, review the latest changes, and reapply your edits rather than overwriting them blindly.

An exact-path publication pins a snapshot for that path. Other paths continue using the global publication. Publishing all pages replaces the global snapshot and clears exact-path overrides. Plan this carefully when different product pages are on different approved releases. Publishing selects a new cache version for subsequent requests; it does not alter responses already delivered.

Rollback: restore the previously approved content into a draft, save, review, and publish the required scope. Publication history supports inspection; there is no documented one-click rollback workflow. For urgent delivery withdrawal, disconnect the managed route or disable your own adapter and serve origin HTML. Revoking a render key stops API delivery for that key; it does not disconnect an independent edge route.

<a id="partners"></a>

## 15. Optional partner and diagnostic integrations

Admins can generate a separate partner key under **Connection → Partner integrations**. These `ov_int_` credentials can read published narrative data, and optionally submit draft suggestions. They cannot render, publish, or replace an `ov_live_` key. Grant draft-write access only when your review workflow is ready.

The [Partner API reference](https://optiview.ai/integrations/) documents published narrative reads, idempotent draft suggestions, and publication-status checks. Suggestions arrive as saved draft blocks with a receipt under Added Content. Review them before publishing. A status such as published_as_submitted describes current publication state, not delivery to an AI model.

Use a stable Idempotency-Key for each logical suggestion and preserve it across retries. Reusing a key with different content returns a conflict. Your integration should handle stale draft versions and never assume a diagnostic finding has been corrected until a human-approved publication is active.

<a id="acceptance"></a>

## 16. Acceptance tests before enabling traffic

Run these checks on authorized public pages in a controlled rollout. A 200 response alone is not a content-quality pass. Record the URL, source mode, time, publication version, representative source facts, and delivered payload.

```
# Ordinary visitor: inspect status, content type, and actual HTML body.
curl -sS -D human-headers.txt 'https://www.your-domain.com/product/' -o human.html

# A crawler name alone must not trigger Markdown.
curl -sS -A 'GPTBot/1.0' -D ua-headers.txt \
  'https://www.your-domain.com/product/' -o ua-response.html

# Explicit content negotiation through the installed adapter/route.
curl -sS -H 'Accept: text/markdown' -D markdown-headers.txt \
  'https://www.your-domain.com/product/' -o delivered.md

# Connected edge Page Guide.
curl -sS -D guide-headers.txt 'https://www.your-domain.com/llms.txt' -o llms.txt
```

### Negative control for supplied HTML

```
curl -sS -o negative-control.json -w '%{http_code}\n' \
  https://app.optiview.ai/api/v1/render \
  -H "Authorization: Bearer $OPTIVIEW_API_KEY" \
  -H 'Content-Type: application/json' \
  --data '{"url":"https://www.your-domain.com/product/","html":"<!doctype html><html><body><h1>System Error</h1><p>Unable to complete your request.</p></body></html>"}'
```

With a valid key, matching verified hostname, active service, and available budget, this recognized error-page source should return 422 rather than a successful brand payload. An earlier authentication or budget error does not establish that the extraction check passed. Keep the response with your test evidence.

- Human and User-Agent-only requests retain normal HTML. A forged crawler name may separately be rejected by your security layer; that is not proof of Optiview routing behavior.
- An eligible Markdown request returns text/markdown and the expected published content. An API-only deployment needs your adapter installed before this test can pass at the website URL.
- Assert factual retention: product names, prices and currencies, variants, meaningful category links, technical tables, and qualifiers. Check for placeholder text, UI controls, duplicate blocks, and malformed links.
- Check homepage, deep product, category, documentation/article, and policy pages where applicable. Test trailing slashes and exact-path versus global publication.
- Submit known error HTML to the Push API and confirm rejection rather than invented brand content. Do not treat its response as a success case.
- Test invalid/revoked credentials, wrong hostname, API timeout, and exhausted-budget handling in your integration environment. Visitors should still receive origin HTML.
- Confirm private/cookie-bearing routes are excluded and no sensitive data enters payloads or logs. Verify cache variants cannot mix HTML with Markdown or one customer with another.
- After an approved content update, confirm a new publication version and the changed content. Confirm your own CDN cache refreshes too.
- Verify telemetry appears in the expected API or proxy channel. Preview traffic must not be used as evidence of organic crawler adoption.

<a id="operations"></a>

## 17. Telemetry, budgets, and routine operations

The domain Overview shows successful API and proxy deliveries across 30 calendar days in UTC. Preview and public demo activity are excluded from that chart. Queued telemetry can take a few seconds to appear. Delivery Telemetry & Usage provides operational usage; estimates and configured cost assumptions are not your Cloudflare invoice.

| Private-beta control | Current limit or behavior |
| --- | --- |
| Render API | 30 requests per domain per minute; 1,000 per domain and 5,000 per workspace per UTC day; shared per-IP controls also apply. |
| Domain browser rendering | 100 attempts per domain and 500 per workspace per day. Attempts, including unsuccessful ones, consume budget. |
| Public Website Preview | 10 requests per IP per UTC hour; three per minute; 30 per hostname per hour; 500 globally per UTC day. Shared capacity can be exhausted. |
| Partner integrations | 1,000 requests per domain per UTC day plus shared per-IP controls. |
| Rendered page cache | Up to 15 minutes, with version changes on publication or rendering configuration changes. |

These are implementation limits for the private beta, not a contracted capacity or SLA. Confirm capacity with the operator before a launch, automated bulk test, or customer rollout. Do not rotate keys to evade quotas. Retry transient failures with bounded backoff and keep your origin fallback active.

Monitor extraction failures, partial content, latency, delivery counts, budget use, and stale publications. Recheck representative pages after CMS/theme releases. Review teammate access and key owners regularly. If service eligibility is paused, optimization/publishing can stop while drafts and history remain accessible; the edge falls back to origin. Customer-managed adapters must implement their own fallback.

<a id="troubleshooting"></a>

## 18. Troubleshooting and failure diagnosis

| Symptom | Action |
| --- | --- |
| Verification fails | Check exact hostname, unexpired challenge, exact TXT/token value, public HTTPS, and direct 200. Meta proof must be in initial head HTML. |
| Verified, but Connect Route fails | Check delegated account, scoped operator token, proxied DNS, origin health, and overlapping routes. Verification alone is insufficient. |
| 401 from Render API | Check the ov_live_ key, secret loading, domain API activation, and whether credentials were rotated or revoked. |
| 403 from API | Check exact-host scope, server-side use without Origin, and workspace service eligibility. Do not move the key into frontend code. |
| 400 / 413 / 415 | Check JSON encoding, URL, Content-Type, request size, and nonempty HTML. Some body parsing/size failures return 400; inspect the error message. |
| 409 or stale draft warning | Reload and reconcile current draft/credential revision, ownership state, or publication scope. Avoid blind retries of state changes. |
| 422 on URL render or Push | Inspect the source: redirect, private/cookie policy, non-HTML, recognized error page, or shell. Submit authorized rendered HTML when appropriate. |
| 429 | A rate or shared compute budget was reached. Back off, inspect the message, and coordinate capacity; do not hammer the public demo. |
| 502 / rendering failure | Serve origin, capture sanitized diagnostics, and retry later within budget. Inspect browser dependencies and source accessibility. |
| Missing prices/categories/table labels | Compare initial and rendered HTML, inspect selector scope and partial warnings, and test the actual page. Do not compensate by inventing source facts. |
| Saved content absent | Check saved versus published state, path match, publication override, and external CDN cache. Public preview examples are not your saved content. |
| Blocked source | Inspect origin/security logs and response details. A denial or system error alone does not identify which WAF blocked it or prove other crawlers are blocked. |

A client-side shell can benefit from rendering if content is available to the bounded browser. A security denial needs authorized access or supplied HTML. No extraction mode automatically defeats your firewall. Avoid removing security controls broadly; diagnose the exact rule and request first.

<a id="security"></a>

## 19. Security, privacy, and deployment boundaries

- Treat ownership proof, dashboard access, render credentials, and partner credentials as separate controls. Use least privilege and exact-host scope.
- Only submit content you are authorized to process. Strip personal, authenticated, confidential, and personalized information before Push ingestion.
- Keep existing robots, authentication, and WAF decisions under your team’s control. Content negotiation is not authentication and is available to any compatible requester.
- If a security exception is necessary, have your security team inspect the actual blocking component and use narrowly scoped rules. Do not allowlist a crawler solely by its User-Agent string.
- Review provider processing, retention, and your organization’s requirements before sending source content. The private beta should not be assumed to meet an unprovided certification, data residency requirement, or contractual SLA.
- Never include tokens, customer records, or private HTML when escalating an issue. Supply a sanitized URL/path, timestamp, status, source mode, publication version, and redacted error instead.

See the [Privacy Policy](https://optiview.ai/privacy/) and [Proof & Methodology](https://optiview.ai/proof/) for public boundaries. Content availability and delivery can be tested; better AI answers, indexing, and citations require separate evidence. There is no guarantee that a named crawler requests Markdown or uses any delivered payload.

<a id="handoff"></a>

## 20. Go-live handoff and support

- Record the workspace, exact hostname, integration mode, public-path allowlist, and responsible business/technical owners.
- Store keys in your secret manager, record rotation ownership, and remove temporary credentials from local test files.
- Attach approved content, source evidence, publication version, and representative before/after payload checks to your internal release record.
- Document timeouts, quota handling, cache invalidation, private-route exclusions, and the tested origin fallback.
- Assign monitoring and an escalation owner. Schedule content review after material pricing, policy, product, or CMS changes.
- Document how to disable your adapter or disconnect the managed route, plus the origin checks to run afterward.

During the private beta, use your established Optiview onboarding contact or workspace operator for provisioning and incident escalation. If you do not have one, [request a pilot](https://optiview.ai/#beta). Provide sanitized reproduction steps and observed responses; do not send credentials. This guide is a technical integration document, not a promise of universal extraction coverage or an availability SLA.

[Open the dashboard](https://app.optiview.ai) · [Server integration examples](https://optiview.ai/docs/) · [Partner API reference](https://optiview.ai/integrations/) · [Frequently asked questions](https://optiview.ai/faq/)