Content SDK glossary

Build-time information about an application, including registered components and SDK package versions, used by SitecoreAI, Pages, and related tooling to align authoring and preview experiences with the running application. Generated by the CLI and stored in .sitecore/metadata.json.

A workflow for registering external React or web components with SitecoreAI, enabling authors to use them in Pages and the Component builder while the component code remains in the head application.

A separate, scoped context ID used for client-side calls, providing restricted, client-safe access so values exposed in the browser cannot be used like a server key. Stored in api.edge.clientContextId, typically sourced from <prefix>_PUBLIC_SITECORE_EDGE_CONTEXT_ID.

A prerequisite for enabling the Design Studio’s code generation feature, where component definitions and metadata are extracted from a Content SDK application and sent to SitecoreAI to support accurate, context-aware code suggestions.

A build-time generated mapping of Sitecore rendering names to their corresponding components in the head application, used by the SDK to resolve renderings when transforming layout data into a page tree and to enable in-context editing.

A pattern in which data is fetched directly within individual components rather than centralised at the page level. Common in frameworks such as Next.js Pages Router, where data fetching is typically coordinated through page-level APIs, this approach is largely superseded in the App Router by Server Components and Cache Components, which change how and where data is retrieved.

A unique identifier used to connect to and retrieve data from a SitecoreAI instance, defining which tenant and resources an application can access when calling Experience Edge APIs. In the Content SDK, separate scoped Context IDs are used for server and client contexts to enable data access without exposing sensitive credentials.

Managed key-value phrases retrieved per site and language, used for UI strings outside of page content.

Placeholder keys that are unique per component instance on a page, typically generated by appending the rendering UID to prevent collisions between duplicate components.

An instance of the same application code as the rendering host, configured specifically for authors, where SitecoreAI directs editing requests to enable WYSIWYG editing.

A shared secret between SitecoreAI and the head app that enables preview and editing endpoints to trust incoming requests, configured as editingSecret or SITECORE_EDITING_SECRET in environment variables.

A user-managed deployed application used as the editing host instead of deploying a one-click host through SitecoreAI.

Components created in the Component builder and staged for use in the Page builder. Often referred to as low-code components, they can display static or dynamic content from external data sources and may include BYOC or other externally defined components.

A customer-built front-end application that consumes content from SitecoreAI and serves as the presentation layer in a headless architecture. It is independently deployed by the customer, integrates with Sitecore’s editing and preview infrastructure, and renders content to end users.

A build-time generated manifest of module imports derived from application components, used to enable Design Studio’s code generation feature and ensure generated components reference the correct modules and paths.

A declarative approach where GraphQL queries are attached to renderings, enabling the Layout service to return component data as query results embedded directly in the layout response as component props.

Presentation structure (like site info, placeholders, and renderings) and component data returned for the requested route.

Serving more than one logical site from one head deployment, with hostname-to-site resolution.

A named region in the layout data where authors insert renderings, enabling editors to define and modify a page’s layout based on how its structure is configured.

Allows you to render your page, component or code in the Page builder, Design Studio or any other application that supports it. Preview mode is meant for CMS use cases where you write draft content (such as in SitecoreAI Pages builder), and you want to render pages with this content at request time, bypassing any static generation or caching.

The public head application that serves the site to visitors, scaled for live traffic and deployed on platforms such as Vercel or Netlify, and retrieves published content through Experience Edge.

A context ID used only in server-side contexts (such as SSR, route handlers, and build-time generation) that grants full access to Edge APIs for layout, content, preview, and related operations. Treat it as a secret and never expose it to the client. Stored in api.edge.contextId, typically sourced from SITECORE_EDGE_CONTEXT_ID.

A configured client object that encapsulates all server-side (or isomorphic) access from your head app to Sitecore content and presentation services. This allow frameworks to use typed methods instead of reimplementing GraphQL, layout, i18n, and other flows.

Command-line interface for the Content SDK, driven by sitecore.cli.config, that supports build and extraction tasks like component map and metadata generation.

The CLI configuration for component map, metadata generation and other operations used during build time by the sitecore-tools CLI.

The root-level Content SDK configuration that centralizes Sitecore connectivity, feature flags, and site and language defaults. This is the single source of truth for the runtime code.