loading

Getting Started

  • Overview
  • Quick Start
  • Instant Preview
  • Try on Other Sites
  • Workspace

Integration

  • Configuration
  • Security & Policies
  • AI Discovery
  • Agent-to-Web (A2W)

Reference

  • API Reference
  • Instant Preview API
  • Examples
  • Roadmap

Platforms

  • Webflow
  • Wix

[ documentation ]

Workspace

Rover Workspace is the owner control plane for Rover runtime launch, settings, and Rover Analytics. It keeps configuration and analytics in one persistent route shell on both supported Rover hosts.

Voice narration and Action Spotlight are explicit owner controls in both direct Workspace setup and managed Webflow onboarding: the Guided preset defaults guide flows to narration plus highlights, uses the SDK narrator with browser speech or entitled Rover narration audio, and gives visitors local Guidance and Voice & language controls for that site. Mascot audio remains a separate setting.

Routing model

Workspace uses nested section routes. The URL preserves the selected site and section while the shell stays mounted:

/rover/workspace/all/home
/rover/workspace/new?flowId=…
/rover/workspace/travel-demo-T3DkiA/journeys
/rover/workspace/travel-demo-T3DkiA/deploy
/workspace/travel-demo-T3DkiA/analytics

Old ?view= links redirect deterministically to these routes.

Information architecture

Home

Activation checklist, install health, the highest-priority next action, and recent changes.

Journeys

Journey drafts, triggers, proactive rules, owner preview, rollout controls, and deterministic manual editing.

Knowledge

Product knowledge, catalog content, Scout scans, and imports.

Actions

Owner actions, private agent tools, handoffs, validation, and security constraints.

Audience

Verified identity, personalization, visitor intelligence, and bounded account/site memory.

Appearance

Theme, mascot, spotlight, voice, narration, motion, and accessibility.

Deploy

Install material, domain policy, verification, discovery artifacts, and site-scoped AI connections.

Analytics

Overview, visits, trajectories, journey outcomes, reviews, interviews, discussions, and memory.

Plan

Usage, credits, forecast, billing, site bindings, and AppSumo-specific guidance.

Account model

Rover Workspace keeps one active Rover session per browser origin, but now remembers recent Rover accounts on that origin so switching is faster and less destructive.

Primary entry: use Get Started from the Rover landing page to open Workspace on the current Rover host.
Switching: the sidebar account menu lists recent Rover accounts plus Use another Google account.
Restore: pending site and Webflow targets are restored after popup or redirect auth, and account-scoped local state does not leak across users.

Sites, Launch/Settings, Install, Quick Test, and analytics

The sites view is the operational control plane. It owns:

  • site search, filtering, and pagination
  • per-site key maintenance such as enable/disable, rotate, and allowed-domain edits
  • site lifecycle actions such as opening Launch or Settings, opening Install or Quick Test, and deleting a site

The setup route is contextual:

  • Guided Launch is the default first-run direct-install flow: Connect site, Shape presence and flow, then Review and test. Standard Rover is the recommended package and already includes Rover Analytics by default. Shape presence and flow exposes the Experience preset, Action Spotlight default/color, voice narration, greeting, voice input, and presence controls.
  • Settings is the returning-user control plane: Presence, Task Flow, Inputs & guardrails, Brand / Motion / Publish, and Rover Analytics. Experience / Motion owns the preset, Action Spotlight default/color, and voice narration, while Inputs & guardrails owns the off-by-default automatic page scrolling control.
  • Webflow Setup remains the managed onboarding flow for Webflow-owned installs, and now writes the same underlying Rover site-config contract as direct Workspace: business type, sparse Rover V3 experience overrides, greeting, voice narration, voice input, AI access, discovery, Action Spotlight default/color, and page capture.

Both Guided Launch and Webflow review are now check-and-change surfaces. The review rows are clickable, and if you jump back to edit from review, Rover saves your changes and returns you to review instead of forcing you through the whole step sequence again.

Workspace writes Rover's canonical siteConfig.experience contract as sparse overrides. Runtime defaults still own the minimized seed, centered stage, focus stream, and attachment-capable dock unless you override a field. Voice, captions, spotlight, and engagement kind are independent; explicit visitor voice-off always wins.

Guided action narration is emitted in-band as response-level roverPresentation by the same ACT or planner model response that chooses the tool/action. The shipped browser runtime consumes that presentation locally for captions, voice, and Action Spotlight; it does not make a separate narration-compose request and the presentation layer never changes tool argument schemas.

Saved journey, playbook, SDK, and URL engagementKind metadata is authoritative. For an untyped natural-language request, the first existing planner or ACT response supplies the canonical Demo, Onboarding, Support, or Task kind from live context. Share links use only ?rover_kind=demo|onboarding|support|task.

Runtime UX now keeps selected file attachments visible as removable chips in both the full panel and minimized bar. The conversation drawer is backed by Rover conversation metadata plus a transcript blob, so prior chats can be listed quickly and loaded lazily instead of disappearing when the widget resets.

The new install view owns generated outputs only:

  • required production install snippet
  • portable test config JSON for Helper, Console, Bookmarklet, and Live Test
  • advanced AI discovery artifacts such as rover-site.json, agent-card.json, the full A2W Link header, and llms.txt

The Rover Analytics views remain read-only. They are powered by owner-authenticated Firestore reads, not public raw siteId GET routes.

Install and Quick Test views

After you create or replace a site key, open install. That page keeps the required production path first and pushes generated testing and advanced discovery lower in the stack:

Production Install: copy the exact Workspace-generated snippet for your real site, or let Rover keep the managed Webflow deploy in sync.
Test config output: copy test config JSON, then move into test or Live Test for Helper, Console, or Bookmarklet flows.
Advanced AI Discovery: collapsed by default, with rover-site.json first as the rich profile, agent-card.json next as the interop card, and the rest clearly marked optional.
Experience defaults: the generated install config includes Rover V3's presence-pill, centered-stage, focus-stream, attachment defaults, guide-flow voice narration, Action Spotlight default/color, and scroll-off page capture via the same experience and page-config contracts that Workspace edits.

The separate test view is the Quick Test surface. Use it when you want Rover-managed previews, Helper handoff, console snippets, bookmarklets, or test-specific recovery actions without mixing those flows into production install copy.

Workspace keeps the full owner-readable pk_site_* install material available for authenticated owners whenever you reopen Install, Scripts, or Quick Test. Rotate only when you want to replace the key, or when a truly old legacy key never stored its public value.

If Live Test tells you This API key is missing capability: roverEmbed, the selected key is not embed-ready yet. Rotate or create an embed-enabled key first.

AI Discovery Outputs

AI discovery now lives behind the advanced section in install. Keep the ordering strict: required snippet first, generated rover-site.json next, generated agent-card.json after that, and only then optional support surfaces.

Required baseline: the Workspace-generated snippet already emits Rover's inline discovery hints, hidden semantic landmark, chatbot cloud GET guidance, and the visible Rover seed/presence cue when AI launch is enabled.
Authoritative rich profile: publish the generated rover-site.json to /.well-known/rover-site.json.
Interop card: publish the generated agent-card.json to /.well-known/agent-card.json. It includes POST A2W, chatbot GET, and A2W GET guidance.
Optional pointers: add the generated HTTP Link header or generated HTML discovery links so generic agents can find the interop card, docs, and A2W run endpoint.
Optional support only: llms.txt stays supplemental but includes the same POST, GET, and A2W GET instructions.
Webflow-managed sites: the advanced artifacts only matter if you also control the live origin, CDN, or another place to publish those files and headers.

If you need stronger machine-readable discovery beyond the snippet, start with rover-site.json, then add agent-card.json. For the full decision tree, read AI Discovery.

Path matrix

PathWhat Workspace providesWhen to use it
Hosted PreviewNothing. Rover makes the temporary preview for you.Fast Rover-managed demos.
Preview HelperTest config JSON.Best multi-page desktop testing path.
ConsoleTest config JSON.Quick current-page DevTools testing.
BookmarkletTest config JSON.Drag-and-click current-page testing.
Production installInstall snippet.Your real site, not arbitrary test targets.

Shortcut builder

Workspace now treats shortcuts as a builder-first configuration surface instead of a raw JSON textarea. The default editor is a structured builder with required fields up front and an optional advanced JSON mode for power users.

Required fields: id, label, prompt
Optional fields: description, icon, routing, engagementKind, legacy engagementKind, enabled, order
Experience kind: use engagementKind to explicitly select Demo, Onboarding, Support, or Task behavior. Voice is configured separately and visitor voice-off always wins.
ID policy: IDs auto-generate in snake_case, but stay editable. Exact IDs are what deep links and A2W run calls use.
JSON mode: invalid or unsupported shortcut JSON never overwrites the last valid saved shortcut set.

Persisted shape

[
  {
    "id": "get_started",
    "label": "Get Started",
    "prompt": "Help me get started and guide me to the best next step.",
    "description": "Short first-run onboarding flow",
    "routing": "planner",
    "engagementKind": "onboarding",
    "enabled": true,
    "order": 1
  }
]

Shortcut IDs in deep links and A2W runs

The exact saved journey ID is what Rover resolves at runtime. Launch & share provides three separate outputs: a browser link for visitors, a compact A2W GET link for URL-fetch chatbots, and a strict A2W POST payload for API agents.

https://example.com?rover_shortcut=get_started
https://example.com?rover_shortcut=get_started&rover_kind=onboarding
https://agent.rtrvr.ai/v2/a2w/runs?url=https%3A%2F%2Fexample.com&shortcutId=get_started&engagementKind=onboarding
{ "url": "https://example.com", "shortcutId": "get_started" }

Use Workspace values in the SDK or helper

Workspace is the source of truth for Rover client setup. For the cleanest path:

  1. Create a Rover site key, or reuse an existing active one that already has the right domains and policy.
  2. Open install and use Copy test config JSON.
  3. Open Try on Other Sites or paste the same JSON into the Preview Helper yourself.

The JSON that Workspace exports is built from:

  • siteId
  • publicKey (pk_site_*)
  • optional siteKeyId
  • allowedDomains
  • domainScopeMode

From there you can either copy the generated production install snippet, or use the same JSON for the Rover website testing tool, the Preview Helper, and the SDK preview helpers.

Authentication model

Rover Analytics site-tag writes still use signed Rover session auth from the embedded runtime. Workspace reads and settings use owner auth and are scoped to sites you own.

Runtime/embed: signed Rover session token, safe for site traffic and public snippets.
Workspace analytics: owner-authenticated Firestore reads scoped by site ownership rules.
Workspace settings: Firebase-authenticated backend callables for private setup that includes masked secrets.
Private config: webhook secrets stay out of the public site config returned to runtime callers.

Rover Analytics notifications

Workspace stores Rover Analytics notification settings per site. These subscriptions are generic webhooks with event filters, auth, retries, payload presets, and optional HMAC signing.

Slack or Discord are treated as webhook destinations and payload formats rather than separate analytics bot products.

Related docs

Instant Preview for Hosted Preview and the high-level split between hosted preview and Workspace-config testing.
Try on Other Sites for the exact Workspace-first Helper / Console / Bookmarklet walkthrough.
Instant Preview API for the signed-in hosted preview contract, curl examples, and OpenAPI spec.
Quick Start for the generated snippet and install flow.
Configuration for runtime boot options and Workspace-owned Rover Analytics settings.
API Reference for direct Firestore Rover Analytics reads, private settings callables, and A2W/agent contracts.