In production
Marketplace SDK · Page Builder extensions · In production

Apps that live inside the editor.

Seven Marketplace apps shipped to date — built with the Sitecore Marketplace SDK and validated through the dogfood loop: every skill file rehearsed against a real app before being committed as agent knowledge.

Back to SitecoreContact Me
What the SDK is
The Sitecore Marketplace SDK exposes an iframe-based extension model — apps live inside Page Builder, Dashboard, Pages editor, and Content Hub, talking to the host via a typed postMessage bridge. Three architectures: client-side iframe (most common), full-stack (Auth0 PKCE for authenticated server calls), or experimental server-to-server. The pipeline supports all three.
How the flow gets here
There is no Marketplace pipeline. There is one engine, and a platform pack that tells it what a Marketplace app is. The pack owns zero stages — its entire behaviour is data: which skills a stage loads, which scaffold command runs, what the definition of done is, and which visual harness /test uses. Before the packs refactor this was spelled inline across the shared commands as platform_target == marketplace conditionals, which meant a Marketplace run inherited Content SDK assumptions it could not use and missed generic assertions it should have had. Promoting four of those — the crawl, the responsive check, the containment check and the motion check — from accidentally-Sitecore-only to core is the clearest thing the refactor bought this track. The whole story is here.
Three dials, not eleven flows

What changes, and what refuses to.

A run answers three independent questions and the answers compose rather than multiply. Two of the three usually stay at their default — and a default has no pack at all, because a missing directory IS the null value. On this track one combination is refused outright: there is no coherent way to rebuild a public website as a Cloud Portal extension, so the validator rejects it by name at resolution time rather than letting a run discover it halfway through.

platform

What are you building on?

marketplaceopt in

What this page is about. The pack supplies the scaffold command (picked from the auth mode), the SDK skill stack, the extension-point route generation, the host-frame visual harness that clips the app out of the surrounding portal chrome, and app registration as what "deployed" means. Zero stages of its own — all of it is data on stages the core already owns.

content-sdkopt in

The other Sitecore track — head applications on SitecoreAI, with CM and editing-host provisioning, a content phase and a live publish. Six stages and two agents of its own. Same engine underneath; that is the entire claim. See the Content SDK page.

nonedefault

The engine with no platform knowledge at all — no scaffold, no provisioning, no release step. Everything above is what a platform pack adds on top of it.

method

Where does the specification come from?

greenfielddefault

The only method on this track, and the null of the dimension — nothing is injected. The spec comes from a one-question-at-a-time interrogation, and /design diverges into up to three UI variants scored against the extension point they have to live inside.

clonerefused

Declared incompatible, and refused by name rather than left to fail somewhere downstream. A clone rebuilds a public website to a parity threshold — pixel, content, design and component fidelity, per page, per viewport. A portal extension has no public source site to be scored against, so the composition is not a hard case, it is an incoherent one.

audience

Who is operating the run?

developerdefault

Every artifact is surfaced as written — the spec, the ADRs, the task breakdown, the code-review and test reports — and the scope dial is answered by the operator at kickoff.

marketeropt in

Additive only, and never a stage override — a contract the validator enforces rather than a convention. A brief instead of a PRD, plain-language discovery questions, and the auth-model question derived from the resolved variables instead of asked. It removes no gates: all five stay on, and the build and final stops split into a human half (brand and visual judgement) and a blocking machine half, because those are the failure classes a non-developer provably cannot see.

One engine, two shapes

What each dial actually does to the run.

The same thing again, concretely. Step one is the engine with every dial at its default; each step after it turns exactly one dial and marks what that dimension changed. This track is the cleanest demonstration of the whole idea, because the marketplace pack inserts nothing and removes nothing — every stage the engine already ran still runs, and what changes is what each one loads, produces and tests against.

  1. core

    The engine, with every pack at its default

    No platform, greenfield, developer. Eight stages, five operator gates and a delivery loop that runs per tranche. This is what is left when the domain has been taken out of it — and proving it still runs clean is the test that the domain really left.

    /create-prd (unchanged)/architect (unchanged)/design (unchanged)/task-breakdown (unchanged)/implement (unchanged)/code-review (unchanged)/test (unchanged)/ship (unchanged)
  2. + platform: marketplace

    Zero new stages — the whole pack is data

    The clearest demonstration that a pack does not have to own stages to change a run. Nothing is inserted and nothing is removed; what changes is which scaffold command runs, which skills each stage loads, what "done" means, and which harness /test uses — an app clipped out of a real portal iframe rather than a page in a browser.

    /create-prd (replaced)auth mode picks the scaffold/architect (unchanged)/design (replaced)scored inside the extension point/task-breakdown (unchanged)/implement (unchanged)/code-review (unchanged)/test (replaced)host-frame smoke, not localhost/ship (replaced)app registration is the release
  3. + audience: marketer

    The same spine, a different conversation

    Additive only — this dimension may never override a stage body, and a validator enforces that rather than a convention. Nothing is added or removed from the flow. What changes is what reaches the operator: a brief instead of a PRD, plain-language questions, technical answers derived instead of asked, and five dials preset so none of them ever gets surfaced.

    /create-prd (replaced)a brief, and 7 plain questions/architect (unchanged)/design (unchanged)/task-breakdown (unchanged)/implement (unchanged)/code-review (unchanged)/test (replaced)human half + a blocking machine half/ship (replaced)nothing technical surfaced

+ added · ⇄ replaced · − dropped · everything unmarked is the same stage the engine already ran.

Skills used

The marketplace knowledge stack.

Twelve skills, declared by the marketplace pack and resolved into a generated brief at every stage that needs them — never a second hand-maintained list, because two lists of the same thing diverge by construction. Each one was dogfood-validated against a real app build before being committed as agent knowledge. The full-stack and client-side variants pull different subsets — the setup-scaffold decision tree at the top picks which apply.

setup-scaffold

Decision-tree entry point — Content SDK head app, Marketplace Client-Side, Marketplace Client-Side + OAuth proxy, or Marketplace Full-Stack. Picked first, picks the rest.

setup-marketplace-client-side

Scaffolds the canonical client-side iframe Marketplace app (Mode A). shadcn-quickstart command, next-app flatten, Vitest stack, useSyncExternalStore template, Chrome Local Network Access headers.

setup-marketplace-full-stack

Scaffolds the Mode A + Mode B Auth0-PKCE full-stack variant with experimental_createXMCClient — for apps that need SSR-side authenticated calls on behalf of a logged-in Cloud Portal user.

marketplace-sdk-client

Entry-point reference for the postMessage bridge to the portal. ClientSDK.init, Provider + singleton, query/mutate/subscribe verbs, extension-point types, response unwrapping, error codes.

marketplace-sdk-xmc

SitecoreAI endpoint reference — sites, pages, agent, authoring, preview, live, content-transfer, search. sitecoreContextId rules, GraphQL endpoints, Mode A vs B response unwrap.

marketplace-sdk-ai

The AI Skills package — generateBrandReview, the params-wrapper trap, ExtractableFile input types, oversized-payload SyntaxError, both module + experimental_createAIClient modes.

marketplace-sdk-extension-routes

Post-scaffold interactive — pick extension points, name routes, generate App Router files, produce the exact values to paste into Cloud Portal → App Studio.

marketplace-sdk-lifecycle

End-to-end lifecycle — custom vs public apps, Cloud Portal registration, the three architectures (client-side iframe / full-stack / experimental server-to-server), Auth0 model, Blok compliance, submission.

marketplace-sdk-testing-debug

Local dev loop — HTTPS + mkcert, test-app registration, Chrome LNA traps, extracting orgId/tenantId/contextId, iframe sandbox constraints, iframe-handshake + cookie debug checklist.

marketplace-sdk-host-frame-testing

Visual smoke recipe — load the app via the host URL, locate the iframe by origin, clip the surrounding chrome, compare against the approved POC clickdummy as the visual ground truth.

sitecoreai-auth

Shared OAuth 2.0 client-credentials auth for all four SitecoreAI APIs (Agent, Pages, Publishing, Sites). Automation-client creation, token caching, 401 handling, the three-segment env-var naming.

blok-setup, blok-theming, blok-marketplace-integration

The Blok design system — shadcn init flow, eight theming token categories (colors, typography, spacing, radius, shadows, sizes, breakpoints, semantic), iframe viewport constraints, public-app submission checklist.

Methodologies

How the agents are trained.

The methodologies are how skill content earns its place. Dogfood validates; real-tenant probes prevent assumption-failure; pipeline-is-a-partnership keeps operator agency. These are not branding terms — they are the operational discipline behind every shipped app.

Dogfood Loop

Every skill file is rehearsed against a real app build BEFORE being committed as agent knowledge. If the skill cannot drive a clean build on the first try, it gets revised. The four latest Marketplace apps (PageShot, QuickCopy, Component Atlas, Last-Edit Trail) were the dogfood targets that validated the current skill stack.

Read methodology →

Pipeline Is a Partnership

The agents do not work in a vacuum. Each command surfaces operator checkpoints, escalations, and assumptions explicitly — never "completed silently." The pipeline succeeds when the operator can audit any decision the agents made, at any stage, without rerunning the work.

Read methodology →

Real-Tenant Probe

Hard-gate every planning stage against a live Sitecore tenant capture before commit. Probes catch the "Sitecore returns a shape no doc page mentions" case at Tranche 1 instead of Tranche 6. Redirect Manager PRD-001 was cancelled at T001 after a probe found a fundamental assumption was wrong — saving weeks of wasted build.

Read methodology →

Skills, For Real

Skills are not prose-to-fill-a-folder. Each one is operational knowledge with hard rules, stop conditions, verification steps, and references. They auto-surface by description match — agents do not have to be told which to load. Twelve marketplace-track skills + eleven content-track skills, all dogfood-validated.

Read methodology →
Apps shipped

Seven live, four dogfood-validated.

Every entry below is a real Marketplace app — most live on the public Marketplace, all running in real tenants. The latest four were the dogfood targets that earned the current skill stack the right to call itself battle-tested.

AI Integration

AI Chat in Page Builder

An AI chat assistant inside Page Builder that understands your Sitecore setup — pages, components, data sources, and structure — helps editors stay focused instead of switching tools. This PoC uses the Sitecore Marketplace SDK and Vercel AI SDK so editors can retrieve context, check publishing and translation status, run brand reviews, update content, create and translate news pages, and manage campaigns, all via natural language inside the editor.

Vercel AI SDKMarketplace
Page Builder

Image Hotspot Manager

A Sitecore Marketplace app that improves how editors place and manage hotspots on images in Page Builder. Instead of manually entering X/Y coordinates, editors click on the image to add hotspots, drag to reposition, and add tooltip text and colors.

MarketplacePage Builder
Page Builder

PageShot

A Sitecore Marketplace custom app that adds a one-button screenshot control inside the SitecoreAI Pages editor. Editors click Capture in a Page Builder Context Panel and get a chrome-free PNG rendered by the SitecoreAI Agent API — then Copy to clipboard, Download as PNG, or Open in a new tab. No OS screenshot tool, no editor chrome, no manual cropping.

MarketplacePage Builder
Page Builder

QuickCopy

A Sitecore Marketplace Page Context Panel app with five one-click copy buttons for the SitecoreAI Pages editor: Live URL, Preview URL, Item ID, Page Title, and a Share Link (Markdown or plain text). Values are pre-fetched the moment the editor opens a page, so clicks are instant — no URL hunting, no digging for Item IDs. Keyboard-shortcut accessible, dark-mode default, with in-place button morphing feedback and honest disabled/error states.

MarketplacePage Builder
Page Builder

Component Atlas

A Sitecore Marketplace app that ships two surfaces from one app registration: a Dashboard Widget for component-centric search and a Page Context Panel for page-centric impact. Type a rendering name to see every page that uses it, or open a page to see its renderings and datasources with +N other pages impact counters. The atlas is built on demand from the Sitecore Agent API, scans pages in parallel for throughput, and caches results for the tab's lifetime — no backend, no persisted index.

MarketplacePage Builder
Page Builder

Last-Edit Trail

A Sitecore Marketplace Page Builder Context Panel app that surfaced the last 5 versions of the active page in the current language — newest-first, with age and (when surfaced) author — directly inside the editor. PRD-000 shipped clean; PRD-001 (Compare view) became a lessons-learned partial failure when first real-tenant smoke revealed nine integration issues despite green tests and build. The product was ultimately retired — but the idea and the methodology lessons it produced are kept. The full breakdown lives in the case study and in "The Pipeline Is a Partnership."

MarketplacePage BuilderLessons Learned
SitecoreAI

Redirect Manager

A Sitecore Marketplace app that puts Redirect Maps where editors actually work — across three surfaces from one install. A full-page workbench with regex authoring and a built-in Test tab that simulates how the Content SDK RedirectsProxy would evaluate a URL step-by-step against the loaded redirect inventory, a context panel that adds a redirect for the page you're editing in one click, and a dashboard tile that surfaces recent activity at a glance. Publishes to the live site in one click. Tells you when the local simulator has drifted from upstream Sitecore/content-sdk — with a Claude Code slash command that re-ports the changes for the engineer. The build itself produced a methodology lesson worth keeping — captured in the case study.

MarketplaceSitecoreAIAuthoring API
Stripe

Paywall Blueprint

The first publicly available worked example of charging for a Sitecore Marketplace app. A public open-source reference that demonstrates a complete paywall flow — freemium layout, the full denial-state UX library, and real Stripe Checkout end-to-end — wrapped around two clean swap-in seams so adopters can fork the repo, replace the payment provider or the entitlement store with a single file, and ship a paid Marketplace app without reinventing the gating pattern.

MarketplaceStripeSitecoreAI
Live findings

The traps this track paid for.

Every one of these cost real debugging time on a real app, and every one is now a skill, an always-on rule or a gate rather than something I have to remember. They share a shape with the Content SDK findings: none of them announced itself. The call returned, the app rendered, the write succeeded — and the thing you actually wanted did not happen.

🪆

The response envelope is nested twice — sometimes

A call through the portal bridge comes back wrapped in the SDK envelope AND the underlying API's own data object, so the value you want is two levels down. Server-to-server mode returns it one level down. The two modes look identical at the call site and differ only in the unwrap, which means code that works in the app breaks the moment it moves to a route handler — and the type system is perfectly happy either way.

🖼️

A localhost screenshot proves nothing about an iframe app

These apps live inside Page Builder, Dashboard and the Pages editor — sized by the host, styled against the host's chrome, and subject to its sandbox. A screenshot of the app served on its own is a picture of something the user will never see. The visual gate loads the app through the real host URL, finds the frame by origin, clips the surrounding chrome away, and compares that against the approved clickdummy.

🔒

Third-party cookies and Local Network Access, in that order

Two separate browser behaviours block the iframe handshake for two different reasons, and both present as "the app just does not load". Cookies must survive a cross-site frame for auth to complete at all; Chrome additionally gates a public page reaching a local dev server behind Local Network Access headers. Neither is a Sitecore problem, and neither is guessable from the symptom — which is why the whole dev loop is written down as a checklist rather than rediscovered per project.

⏱️

The write succeeded and the UI still showed the old state

After a purchase completes, the entitlement is real on the server and stale in the browser. The instinct is to poll on mount, which costs every user a request to learn nothing. The right shape is to refresh on the transition that can actually change the answer — and to render the pending state honestly rather than optimistically, because an optimistic UI that guesses wrong is worse than a spinner that is right.

🔑

An idempotency key that outlives its parameters is a bug

Reusing a key after changing what the request says does not deduplicate — it replays the old call and returns the old answer, silently. The key has to be derived from the parameters it protects, so a changed request is by definition a new key. Adjacent lesson from the same integration: a field the SDK removed in a major version disappears from the types but not from anybody's mental model.

🛑

The best run is the one that gets cancelled at task one

Redirect Manager's first spec was killed after a probe against a real tenant found that a foundational assumption about the field shape was simply wrong. A day of probing replaced several weeks of building the wrong thing. That is not a failure mode, it is the mechanism working — which is why any plan resting on an unverified assumption now gets a probe tranche first, and a refuted probe counts as a successful outcome.

Case studies

How each one actually shipped.

Each case study is the full agentic write-up — the PRD, the architecture, the ADRs, the friction log, what went well, what got iterated, and the framework learnings that landed back in the pipeline.

Paywall Blueprint

11-card bento dashboard · Stripe integration · live in prod

Read case study →

Redirect Manager

Sitecore redirect maps · the multilingual cancellation lesson

Read case study →

Last Edit Trail

Partial-failure case · operator-triaged trade-off · framework learnings

Read case study →

Component Usage Atlas

Rendering inventory · host-frame smoke methodology proven

Read case study →

QuickCopy

Cross-tenant content copy · SDK-types refactor · design-polish-1 shipped

Read case study →

PageShot

Visual page captures · v1 of the dogfood loop

Read case study →
Need an editor-side tool?

Want a Marketplace app built this way?

Custom or public, client-side iframe or full-stack Auth0 — the pipeline handles every variant. If you have a Page Builder extension on the horizon, reach out.

Mail MeAgentic Pipeline