Developer docs

Twinlet developer docs

How public Twinlet data is projected, authenticated, and served across web, API, MCP, and static mirrors.

These docs are public — no account is needed to read them. Key issuance and twinlet management live in the product.

7 sections · 0 published · 3 draft · 4 plannedStatuses are honest: nothing on this page claims a shipped, versioned contract yet.

Public projection

Planned

Which data classes can ever be public, how the approved-projection pipeline decides what ships, and how projections stay fresh.

Public data classes
Approved-projection pipeline
Freshness + staleness labels
Revocation propagation

/getting-started/projection · contract not published yet

Authentication & sessions

Planned

The WorkOS/AuthKit session model, server-owned identity, and how roles map to what a caller can see.

AuthKit session model
Server-owned identity
Creator / operator / viewer roles
Session lifecycle

/getting-started/auth · contract not published yet

API reference

Draft

Endpoint reference for profile, sources, readiness, routing, retrieval, and answer/grounding, plus key issuance, scoping, and rate limits.

Profile · sources · readiness
Routing · retrieval · answer
Key issuance + scoping
Rate limits

/getting-started/api · contract not published yet

MCP server

Draft

The available MCP tools, their read-only parity with the API, and how to connect a harness.

Tool catalog
Read-only API parity
Connection setup

/getting-started/mcp · contract not published yet

Static mirrors & discovery

Draft

The Markdown mirrors, discovery JSON, and llms.txt routes — what each contains and how they stay in sync with revocation.

Markdown mirrors
discovery.json
llms.txt
Revocation sync

/getting-started/mirrors · contract not published yet

No-leak expectations

Planned

The public contract for what is never in any output — raw transcripts, quotes, prompts, provider payloads, object keys, key values — the distilled-only guarantee, and how to report a suspected leak.

Never-in-output list
Distilled-only guarantee
Leak reporting

/getting-started/no-leak · contract not published yet

Route boundaries

Planned

Which routes are public, creator-gated, or admin-only — and what a 403 does and does not confirm about a twinlet's existence.

Public routes
Creator-gated routes
Admin-only routes
403 semantics

/getting-started/routes · contract not published yet

What lives where

The ownership boundary this docs site depends on. If a fact is on the wrong surface, it drifts: docs hold contracts, the homepage holds the product story, Studio holds the creator's private workspace copy.

Docs

/getting-started · publicDevelopers and agent builders

Technical contracts and integration facts.

Owns

Projection, auth, API, and MCP contracts
Mirror and discovery file contracts
The public no-leak statement
Route classes and 403 semantics
Versioned changelog for all of the above

Never hosts

Marketing hero or product story copy
Join-the-beta and onboarding flows
Key issuance UI or key values
Creator workspace copy from Studio

Homepage

/ · creator-gatedInvited creators

The product story and Join-the-beta.

Owns

Creator value proposition
Product story and demo framing
Join-the-beta call to action

Never hosts

Endpoint tables or rate limits
Key scoping and issuance rules
Integration contracts of any kind

Studio

/studio · signed-in creatorThe creator-owner of a twinlet

The creator's private workspace copy.

Owns

Source, readiness, and publishing states
Key issuance, scoping, and revocation UI
Private per-twinlet guidance and copy

Never hosts

Public contract text (docs link in, never copy)
Public marketing copy

Routing rule: a sentence that promises behavior to an integrator lives in Docs. A sentence that sells the product lives on the Homepage. A sentence that operates one creator's twinlet lives in Studio. Docs link to Studio for actions like key issuance — they never duplicate its copy.

Getting started

Three steps to a first call. Key management lives in the product — these docs describe it, they never perform it.

Step 1

Get access

Reading these docs needs no account. Calling the API or MCP server needs a key issued for an approved twinlet — product access is creator-gated this phase.

Step 2

Issue a key in the product

Keys are created, scoped, and revoked in the product (Studio → Public/API). A key value is shown once at issuance, in the product only.

Docs describe issuance and scoping. They never display, store, or manage key values.

Step 3

Make the first call

Start with a read-only readiness check over REST or the MCP tool with the same name. Both surfaces return the same distilled-only payloads.

# REST
GET /api/twinlets/@jane/frontend-engineer/readiness
Authorization: Bearer …

200 { "twinlet": "@jane/frontend-engineer", "readiness": "…", "checkedAt": "…" }

# MCP (read-only parity with the API)
get_twinlet_readiness { "twinlet": "@jane/frontend-engineer" }

Schematic example — field names only. Placeholder values are redacted (…); key values and transcript text never appear in docs examples.

Versioned contracts

Every published section carries a contract version. Breaking changes ship as a new version with a changelog entry — never as a silent edit.

Changelog

Planned

A public changelog for this docs site is planned at /getting-started/changelog. Until it ships, the section status badges on this page are the change signal.

Revocation propagation

Revoked twinlets disappear from every surface — web, API, MCP, and static mirrors — including the examples on these docs pages. A revoked handle in an example is removed, not cached.

Storybook-backed docs spine rendered from reviewed fixture data at 2026-07-04 09:30 UTC. Search is a visual affordance while the docs index is static; section routes open explicit unavailable pages until their contracts are reviewed and published.