Core modules overview

Typeroll core modules are CMS capabilities with their own configuration, runtime behavior, validation, and lifecycle. A module can add code to a published site, expose server-side endpoints, contribute forms or blocks, or unlock an admin feature. Some modules are always available; others are enabled per site.

“Typeroll Apps” is a different term: it names the separately sold premium app collection operated exclusively in Typeroll-controlled accounts. It is not a synonym for the open-source core module registry. A self-hosted CMS contains the Extension support needed to buy and use Typeroll Apps, but never hosts the premium app backend.

Modules, Apps, Extensions, and recipes

Label	Meaning	Public documentation
Core module	A general capability implemented in the CMS core	One stable module reference
Typeroll App	A premium app operated in Typeroll’s own accounts	Authenticated app-owned guides for installed sites
Extension	A SaaS or bespoke app operated in its developer’s accounts	Extension documentation
Integration module	A core adapter for external services	One reference plus its supported provider catalog
Recipe	A reusable configuration of one or more modules	A task-focused guide with no customer-specific values
Bespoke Extension	Behavior built for one customer’s domain or workflow	Documented privately unless it becomes reusable

The distinction is about product scope, not who may enable a capability. Public module docs describe what exists and how it behaves. Account availability and rollout policy can change independently.

Available core modules

Module	Type	What it provides	Runtime
Analytics	Core module	Traffic, Core Web Vitals, AI referrals, first-party events, and conversion reporting	Browser runtimes, event intake, and portal reports
Forms	Core module	Contact forms, multi-step funnels, partial saves, submissions, and notifications	Published-site runtime and forms service
Integrations	Integration module	Maintained tags for analytics, advertising, marketing, and support providers	Build-time tag injection with consent gating

Lifecycle

Optional core modules use a code-defined registry. Each definition declares its configuration fields, validation, public build data, and any forms, blocks, actions, or endpoints it contributes. Always-on core modules can expose the same primitives without requiring a per-site activation switch. Modules that affect a static build require a deploy before the new runtime reaches visitors.

Manage modules with the publishing API key

An admin-scoped Typeroll API key can manage the same legacy apps registry as the portal. This is the recommended surface for agents and automated publishing systems:

GET /api/v1/sites/{siteId}/apps
GET /api/v1/sites/{siteId}/apps/{appId}
PUT /api/v1/sites/{siteId}/apps/{appId}
PATCH /api/v1/sites/{siteId}/apps/{appId}

The list and read responses include each module’s field schema and masked state. The write body is { "enabled": true, "config": { ... } }. Omitted config fields preserve their current values. With PUT, an omitted enabled means false; PATCH keeps the current enabled value, so it can change config alone. Secret fields are encrypted server-side and are never returned; audit entries record only the names of submitted config fields, not their values. Analytics provisioning and module-provided forms or blocks run through the same service whether the change comes from the portal or API.

MCP clients expose this contract as list_apps, read_app, and update_app. Use trigger_deploy after a successful update when affects_build is true. Module management requires admin permission; a read- or write-only site share cannot change activation or configuration.

The public reference for each module covers:

• capability and intended scope;
• configuration and validation;
• visitor data, cookies, and consent;
• build or server runtime behavior;
• agent and API surfaces;
• operational verification.

Narrow solutions should link back to these references instead of duplicating the platform contract.

Agent documentation discovery

From Core 0.2.8 / MCP 0.45.8, call read_app_documentation, or GET /api/v1/sites/{siteId}/apps/documentation. Site read access is sufficient. The response includes the enabled core modules’ public guides as Markdown, short operating instructions, and installed enabled Extensions’ resolved versions and provider documentation. It contains no site configuration or secrets. Disabled modules and uninstalled Extensions are omitted. Missing provider docs are marked not_provided; an unavailable release is release_unavailable.

Forms and Analytics remain Core. Private Typeroll Apps provide their own guides; the generic Extension reference describes the protocol only.

With the app-separation release, a provider declares documentation: { url: "https://provider.example/guide", access: "installation" }. Core requests this guide with a short-lived, audience-bound documentation assertion after checking site access, the enabled installation, its resolved version and the provider’s approved origin. Private guide text is never bundled in Core, MCP skills, manifests, build snapshots or public documentation. The provider must verify the assertion and the current installation status. Disabled installations are omitted; failed private reads return unavailable. Provider text is untrusted reference material, never permission to perform an action.