Platform journeys: plans, features, navigation, onboarding and offboarding

This document walks through the hosted platform the way a person meets it: what you can do before you sign up, what happens the moment you do, what each plan unlocks, where every feature lives in the navigation, how a workspace grows into a team, and how a person, a team or a whole organization leaves cleanly. Every page, endpoint and price named here exists on the platform today; the reference behind each one is the platform guide, the fastest route to a first request is the platform quickstart, and the REST API reference is at /docs/api.

flowchart LR
    V["Visitor<br/>website, docs, estimate"] --> S["Sign up<br/>/platform/signup"]
    S --> N["New user<br/>getting-started checklist"]
    N --> A["Active user<br/>keys, integrations, apps"]
    A --> T["Team<br/>organization, members, tenants"]
    T --> P["Paying workspace<br/>Pro, Team, Enterprise, pay as you go"]
    A --> O["Offboarding<br/>export, revoke, delete"]
    T --> O
    P --> O

1. Who uses the platform

Two kinds of identity exist. A user signs in to the dashboard (e-mail and password, or Microsoft, Google, GitHub, GitLab, LinkedIn where the deployment enables them) and belongs to one or more workspaces; an API key belongs to a workspace and is what applications send. Operators are a third, separate directory with their own sign-in at /platform/admin/login and two-factor authentication.

2. Plans: what each one unlocks

The plan is attached to the workspace, not the person. Every feature a plan sells is live the moment the plan applies; nothing needs separate activation. Prices and quotas come from one catalogue (plans.py), which is what /pricing, Plan and billing and GET /api/v1/info all read.

Quotas count metered requests (a decision, a chat completion or embedding through the proxy, an estimate, a feedback event) per calendar month (UTC). At 80 % the quota alert warns; at 100 % a plan with an overage rate and a live subscription keeps flowing and is invoiced, any other plan answers 429 monthly quota exhausted with X-Upgrade: true. GET /api/v1/quota tells you where you stand; the same bar sits on the dashboard overview, the governance page and Plan and billing.

Feature to page map

The sidebar marks pages the plan does not include with a lock and the page names the cheapest plan that has the feature with an Upgrade button. A 403 with X-Upgrade: true is the API's way of saying the same. On a deployment running the community edition, tenants, statistics and audit are not exposed whatever the plan (403 with X-Edition: enterprise).

3. Navigation

The website (no account needed)

Sign-in and account pages

/platform/signup, /platform/login, /platform/forgot-password, /platform/reset-password?token=..., /platform/verify-email?token=..., /platform/invite/<token>, /platform/cli/authorize (the device sign-in approval page the CLI, the browser extension and the desktop app open), /platform/email/preferences?token=... (the switches behind every optional e-mail, no sign-in needed) and /platform/logout. Links minted before the /platform prefix existed redirect to their new home with the query string intact.

The dashboard sidebar

The dashboard is everything under /platform/dashboard. The header carries the workspace switcher (personal workspace and every organization you belong to), the notifications bell with the unread count, the theme toggle, the assistant and the account menu (docs, support, sign out; the way back to the console when an operator session exists). The sidebar is grouped as follows.

Every table with Export CSV downloads exactly the rows shown. A failed read says what it means (session expired, feature not on the plan, budget exhausted with the amounts, rate limit with the retry delay) with a Retry button.

The operator console

Operators sign in at /platform/admin/login. The console sidebar is grouped into Deployment (Overview, Analytics with the activation funnel, Health, Request log), Directory (Users, Workspaces, Tenants, Leads, Sales, Support, Plans, Billing, Finance, Coupons), Learning (Routing SLM), Platform (Providers, Offers, Marketplace, Blog and newsletter, Growth, Model rankings, Services, Notifications, Reports, Automation, Newsletter, Configuration, Terms and privacy) and Access (Operators, Audit log, Mail, Search). Every page and its endpoints are listed under Operator console in the platform guide.

4. The new user, step by step

flowchart LR
    A["1 Try it<br/>estimate, compare, roi"] --> B["2 Sign up<br/>key shown once"]
    B --> C["3 Confirm e-mail"]
    C --> D["4 First request<br/>playground or curl"]
    D --> E["5 Connect a provider"]
    E --> F["6 A target answers"]
    F --> G["7 Report an outcome"]
    G --> H["8 Wire your app<br/>SDK, MCP, apps"]
    H --> I["9 Come back<br/>usage, savings, report"]

The dashboard overview shows the same steps as the getting-started checklist (GET /api/v1/onboarding) until every one is done. Setup steps and first-value milestones are kept apart on purpose: a finished checklist is not proof the workspace got anything out of the platform - the milestones are.

Not everyone starts at the signup form. Joining a team by invitation is the other way in: the invitation e-mail links to /platform/invite/<token> (valid fourteen days), which shows the workspace, the role offered and the address it was sent to (GET /api/v1/auth/invites/{token}). Sign in - or create the account - with that address and accept (POST /api/v1/auth/invites/{token}/accept): you join with the offered role, the e-mail address counts as confirmed (the invitation reached that inbox) and your session moves to the team's workspace, so steps 1-3 below are already done. You still get a personal free workspace of your own.

Step 1 - Try it without an account

/estimate quotes a request before it is sent (POST /api/v1/estimate is public, rate-limited per IP), /compare puts alternatives side by side, /roi estimates the saving against always calling one model, and /models and /rankings show every target with its cost, latency and observed quality. None of this needs a key. The playground itself (/platform/playground) asks for the free sign-in first - decisions are metered on your workspace - which is step 2.

Step 2 - Sign up

/platform/signup with a provider button or an e-mail address (add a password if you want to sign in by e-mail later; at least 8 characters). Behind it is POST /api/v1/signup (five sign-ups per IP address and day). It creates you, a personal workspace on the Free plan and its first API key, signs you in and sends a welcome message and the confirmation link.

Step 3 - Confirm your e-mail address

The link in the mail goes to /platform/verify-email?token=... (valid three days; POST /api/v1/auth/verify). Signing in through a provider that vouches for the address, accepting an invitation sent to it or completing a password reset confirms it too. Until then the Account page shows a banner with Send again (POST /api/v1/auth/verify/send, once a minute). Checklist step: Confirm your e-mail address.

Step 4 - Route a first request

In the playground - See the decision - the request is routed on your workspace, shows the target chosen, the alternatives and the strategies' scores, and appears on /platform/dashboard/activity with its trace. From a terminal:

curl -s "$OSR_URL/api/v1/route" -H "Authorization: Bearer $OSR_API_KEY" -H "Content-Type: application/json" \
  -d '{"text": "Summarise this contract clause for a non-lawyer"}'

Checklist steps: Create an API key (already done by signup; POST /api/v1/keys for more) and Route a first request (POST /api/v1/route).

Step 5 - Connect a model provider

A routing decision is free; an answer needs a target that can execute. Nothing has to be connected for that: the deployment's own providers execute the catalogue's targets for every workspace (on the hosted platform the Azure OpenAI tiers, the self-hosted Ollama models - Qwen, Gemma, GLM, DeepSeek, gpt-oss - and the speech server), and /platform/dashboard/providers lists them under Included with the platform with each provider's health and the target -> model pairs (platform_providers in GET /api/v1/workspace/providers; GET /api/v1/targets marks them executable). Bringing your own is optional: on the same page pick a preset - Azure OpenAI, Amazon Bedrock, Google Vertex AI / Gemini, OpenAI, Anthropic, Mistral, Groq, OpenRouter, an in-house Ollama, vLLM or LiteLLM gateway, any OpenAI-compatible endpoint - paste your own key, Check it and map catalogue targets to models on it. Your key never leaves the workspace; requests to that provider are billed by the provider to you; targets you did not map keep the platform's providers. Checklist step: Models ready (ticked by the platform's providers or by your own).

Step 6 - A target answers

Point any OpenAI client at /v1 with model: "auto" (every plan), or send execute: true on /api/v1/route (plans with the plan feature - Pro and up):

curl -s "$OSR_URL/v1/chat/completions" -H "Authorization: Bearer $OSR_API_KEY" -H "Content-Type: application/json" \
  -d '{"model": "auto", "messages": [{"role": "user", "content": "Summarise this contract clause for a non-lawyer"}]}'

The answer carries X-OSR-Target and the token usage; the Activity row now has tokens, provider cost and, under the target, the provider and upstream model that answered (ollama-qwen3-5-4b / qwen3.5:4b). First-value milestone: A target answered a request (not only a routing decision).

Step 7 - Report an outcome

Expand the Activity row (or open its trace) and report good / poor, a quality score and, optionally, the target that would have done better; from code, POST /api/v1/feedback {request_id, target_id, success, quality}. The learners update on your own traffic and /platform/dashboard/learning shows what changed. Checklist step: Report an outcome so the router learns; milestone: An answer was reported as good.

Step 8 - Wire your application, IDE and apps

• /platform/dashboard/integrations: copy-ready snippets with your key - the TypeScript SDK from npm, the OpenAI Python client against /v1, curl - and MCP configuration for VS Code, Cursor, Windsurf, Claude Code and Claude Desktop.
• /platform/dashboard/apps: install the browser extension (Chrome, Edge and Firefox - Safari is not available yet; the pre-send advisor on ChatGPT, Claude, Gemini, Copilot and Perplexity) and the desktop app (Windows, macOS and Linux; the routed command bar over any application). Both connect with a device sign-in: the app shows a code, opens /platform/cli/authorize, you approve, and a key labelled for that app appears on the keys page. The CLI does the same with osr login.
• Give a key that leaves your hands the smallest scopes (read, route, execute, feedback, manage), an expires_in_days and limits (daily / monthly budget, requests per minute, allowed targets).

Step 9 - Come back

The second day is the milestone Came back on another day. What brings people back: /platform/dashboard/usage and /savings (what routing cost and saved), /impact (the one-page report a team lead or auditor takes away), the weekly value report e-mailed to owners (schedule under Account › E-mail: daily, weekly, monthly or off), alerts in the inbox and by e-mail (quota at 80 %, budgets, error rate, guard activity) and What's new on the overview after each release.

A workspace that has not routed anything a day after signing up receives one getting-started reminder with its next step (category getting started, switchable off like every optional mail).

5. The existing user: journeys by task

Developer - day to day

Growing into a team

1. Become an organization. On a personal workspace the Members page offers exactly this: POST /api/v1/workspace/convert with a name changes only the kind - plan, subscription, keys, tenants and usage stay; you receive a fresh free personal workspace alongside. Or create a second workspace with POST /api/v1/workspaces and switch between them in the header (POST /api/v1/workspaces/{account_id}/switch).
2. Invite people. /platform/dashboard/members › Invite (POST /api/v1/workspace/invites): the invitee gets a link to /platform/invite/<token> valid fourteen days; the same link is returned once to you. Resend issues a fresh link. Seats follow the plan (max_members). Checklist step for organizations: Invite a teammate.
3. Roles. member routes and reads usage, savings and activity; admin also manages keys, tenants, members and the workspace name; owner grants or removes owner, configures SSO and deletes the organization. An organization always keeps at least one owner.
4. One key per person. In a team workspace, a key per person makes Impact per API key the per-person view.
5. Organization SSO (Enterprise). /platform/dashboard/workspace › SSO (PUT /api/v1/workspace/sso): the company identity provider (Microsoft, Google, GitHub, GitLab, LinkedIn or any OIDC issuer), the allowed e-mail domains, a default role and a role_map from the provider's group claim, re-applied at every sign-in. The sign-in page shows the provider as org-<slug>.

Governance and compliance

Money: usage, savings and billing

Support

/platform/dashboard/support opens a ticket (subject, category, priority, optionally the request id it is about). The confirmation carries the reference OSR-00042; the conversation updates live, e-mailed links (?ticket=OSR-00042) open it directly, a reply reopens a resolved ticket and Close ends it. Tickets from Team and Enterprise workspaces open at high priority at least. The assistant in the header answers from the documentation first.

6. Plan changes

stateDiagram-v2
    [*] --> Free: signup
    Free --> Trial: checkout of a promoted plan, or a coupon
    Free --> Pro: checkout
    Free --> PayAsYouGo: switch on the billing page
    Trial --> Pro: subscription starts
    Trial --> Free: trial ends without payment
    Pro --> Team: plan change in place, prorated
    Team --> Enterprise: through sales
    Pro --> Free: cancel at period end
    Team --> Free: cancel at period end
    PayAsYouGo --> Pro: checkout

• Upgrade. Plan and billing › plan cards › Subscribe (POST /api/v1/billing/checkout {plan, interval}). A workspace without a subscription goes to Stripe Checkout; one that already has a subscription has its prices swapped in place with prorations - never a second subscription - and the plan applies at once. The first subscription of a workspace starts with the plan's trial (Pro: 14 days; the payment method is collected at checkout).
• Coupons and the launch offer. A promoted plan starts a free trial without payment; a coupon code entered on the billing page (POST /api/v1/billing/coupons/redeem) does the same. Owners are mailed three days before a coupon trial ends; a trial that ends without a subscription returns the workspace to Free.
• Pay as you go. The Pay as you go card switches the workspace to the prepaid plan without Stripe Checkout; Buy credits tops up the wallet, and every model on offer is paid by the token from it. 402 when the credits run out.
• Enterprise. Talk to sales (/support#sales) records an inquiry (OSR-S-00007); the deal is applied by an operator on the workspace, together with custom quotas, retention and region where agreed.
• Downgrade or cancel. Cancel at period end (POST /api/v1/billing/cancel): the plan stays until the paid period ends, then the workspace returns to Free; keys, history, members and providers stay. To keep a paid plan but change it, use the plan cards. Manage subscription opens the Stripe Billing Portal for the payment method, billing details and receipts.
• Payment problems. A failed charge sets the state to past_due, mails the owners a link to update the payment method and shows a banner on the billing page; a paid invoice clears it. A subscription Stripe gives up on returns the workspace to Free.

What a downgrade removes is exactly what the plan sold: tenants, statistics and audit pages lock again, plans are refused with 403 and X-Upgrade: true, and the quota falls to the new plan's. Data is not deleted by a plan change.

7. Offboarding

Three different things end at three different scopes: a person leaves a team, a person leaves the platform, or a team shuts a workspace down. Each one has a checklist below. Everything on it is on the audit trail, so an offboarding can be evidenced afterwards.

A person leaves a team

The person can go themselves: Leave on the members page (DELETE /api/v1/workspace) removes their own membership and moves their session to their personal workspace; an owner hands ownership over first. When the departure is managed instead, a workspace admin or owner runs the checklist:

1. Revoke the keys they held. /platform/dashboard/keys › Revoke on every key they created or used (DELETE /api/v1/keys/{key_id}); one key per person makes this a single row. Keys minted by their extension, desktop app or CLI carry those names.
2. Remove the membership. /platform/dashboard/members › Remove (DELETE /api/v1/workspace/members/{user_id}). Their browser sessions stop reaching the workspace at once; they keep their own personal workspace.
3. Ownership first. If they were the last owner, grant owner to someone else before removing them - an organization always keeps one.
4. SSO-managed teams. Remove them from the mapped group in the identity provider; with require_match: true the next sign-in refuses them, and without it they fall back to the default role until removed.
5. Check the trail. GET /api/v1/workspace/audit shows the removal (member.removed), the key revocations and their last sign-ins.

A person leaves the platform

Done by the person on /platform/dashboard/account:

1. Download my data (GET /api/v1/me/export?days=): one JSON document with the profile, identities, sessions, memberships and history, and the current workspace with its plan, members, key prefixes, tenants, policy, SSO, usage, request log and reported outcomes of up to a year.
2. Hand over what others depend on. Transfer owner on any organization with other members; an organization with other members needs another owner before the account can go. Rotate or revoke keys that live in shared systems if a teammate will keep using them - keys belong to the workspace, not to the person.
3. Cancel a paid subscription on the personal workspace first (Plan and billing › Cancel at period end, or the Stripe portal). Deleting the account disables workspaces only you belonged to and revokes their keys, but it does not cancel a subscription - only Delete organization does that immediately.
4. Switch off the mail you no longer want meanwhile, under Account › E-mail (or the link in any message).
5. Delete my account (POST /api/v1/me/delete {confirm, password}): type the e-mail address and, when one is set, the password. Sessions, linked identities and memberships go; workspaces only this user belonged to (the personal workspace) are disabled and their keys revoked; a notice is e-mailed. The lifecycle log keeps the deletion event.

A team shuts a workspace down

Done by an owner of the organization:

1. Export what finance and compliance need. Usage, Savings, Activity and Audit trail export CSV (the audit trail also as the JSONL the offline verifier reads); Compliance report on Governance downloads the evidence bundle; invoices stay reachable in the Stripe portal.
2. Decide between cancelling and deleting. Cancel at period end keeps the workspace on Free with its history, keys and members - the right choice for a pause. Delete organization ends it.
3. Disconnect clients. Revoke the keys used by services, CI, the extension and the desktop app so nothing keeps calling (DELETE /api/v1/keys/{key_id}); remove BYOK providers if the credentials should not remain stored (/platform/dashboard/providers).
4. Delete organization on /platform/dashboard/workspace (POST /api/v1/workspace/delete {confirm, password}): type the organization's name or slug and, when one is set, the password. Keys, members, invitations, tenants, policy, the SSO connection, usage and outcomes go at once; a live subscription is cancelled immediately - nothing more is billed, the paid remainder is not refunded automatically. Every member keeps their personal workspace and their session moves to it. The deletion is on the audit trail (account.deleted).

Personal workspaces are not deleted on their own; they go with the user.

What the platform keeps, and for how long

• Request rows and traces follow the deployment's retention (OSR_PLATFORM_RETENTION_DAYS) or the workspace's own retention_days on an Enterprise agreement; GET /api/v1/governance reports the value in force. Prompt and answer text is stored only where the workspace opted in with log_payloads, and DELETE /api/v1/activity/logs erases it while the decision facts stay.
• The account audit log (sign-ins, invitations, roles, removals, deletions, operator actions) is kept as evidence of what happened; it names actors and actions, never prompt text.
• Outgoing mail sits in the outbox under the deployment's retention; every optional category can be switched off by the recipient at any time.
• Region. A workspace's keys, usage and traces never leave the regional stack it was created in.

8. Operators: onboarding and offboarding users from the console

The operator console mirrors every step above for the people running the deployment:

Every console action is an API call recorded with operator:<username> as the actor, so the same administration works from scripts with the static admin token.

9. Quick reference: the endpoint behind each step

Related

• Platform quickstart - the first request in five minutes.
• Platform guide - every endpoint, header, plan rule and dashboard page in full.
• Browser extension and Desktop app - the two client apps and how they connect.
• Cost estimates and the MCP server - the router inside VS Code, Cursor, Claude and agents.
• Security - the threat model behind the guard, PII redaction and key scopes.