[NguyenQuangHuy-Harry]

Proposed type

• Type: application/storefront-page
• Actions: both create and edit
• One-line summary: A merchant-authored storefront page — content and layout that an app builds and publishes to the online store.

Why this type

Real merchant asks this captures:

1. "Build me a landing page for the summer collection launch" — the canonical page-builder ask, and today there's nothing in the catalog to route it to.
2. "Add a testimonials section to my Black Friday page" — an edit that currently means finding the right app, the right page, and the right insertion point by hand.
3. "Spin up a landing page for this ad campaign" — the destination step after an application/ad intent, where the two types compose.

Storefront page building is a mature, multi-vendor App Store category and currently the largest one with no way to register an intent.

Who would register intents for it

• PageFly (ours) would register both actions.
• The page-builder category maps cleanly onto the same artifact: GemPages, Shogun, Replo, EComposer, Zipify Pages, LayoutHub. Theme-section and template marketplaces that publish pages on a merchant's behalf fit the same shape.

The design constraint I worked to: two page builders will never agree on a component tree, but they can agree on "a page titled X, for surface Y, featuring products Z, roughly these sections."

Schema sketch

Full draft is inline in types/application-page.md in this PR. Shape summary: id, title, handle, page_type (home/product/collection/blog_post/page/password), goal, sections[] (type, heading, body, media_url), products[]/collections[] GIDs, status, seo.

Deliberately excluded, as app document-model concerns rather than merchant-facing ones: element and component trees, style objects, breakpoints, template file bindings, revision history.

Confirmed:

• inputSchema does not declare required fields
• Field names are consistent with neighboring types in types/ — snake_case for multi-word fields, matching the fields proposed on application/email (body_html, reply_to, template_id)
• For application/*, the schema refs the canonical application schema (TOML example $refs the would-be canonical URL; draft inline pending publication)
• For shopify/* — n/a

Prior art

• shopify/product with import covers "build a page for this product", which is real and useful. It can't express a page with no single anchoring resource — an About page, a campaign landing page, a multi-product comparison — and it carries no page-level intent (title, handle, outline, goal).
• application/campaign describes the campaign's schedule, audience, and channels. A page is usually the campaign's destination, and most pages have no campaign behind them at all.
• application/faq already covers the case where the page is an FAQ, and should keep doing so. The shapes differ: question-and-answer versus section outline.
• application/theme-edit-task (proposed in discussions) targets theme code; this targets a merchant-authored page.

Anything else

Three things I'd rather have your read on than guess at:

1. Is sections too app-specific to carry? It's the field most likely to vary between builders. Dropping it and letting goal carry the whole intent is a legitimate alternative, at the cost of structure Sidekick could otherwise pre-fill. Related: every published application/* schema except email is currently id plus additionalProperties: true, so if the house style is to ship minimal and let apps extend, I'm happy to cut this draft back a long way.
2. Closed enum or open string for page_type? Closed is safer for routing; open avoids a schema revision each time a new storefront surface appears.
3. Is a publish action out of scope? Every application/* type in types/ declares exactly create and edit, so I've followed that — but "publish the page I made yesterday" is a plausible merchant ask, and it's a state transition rather than an edit. Happy to leave it out if the omission across the catalog is deliberate.

Two small conventions I diverged on, both easy to revert if you'd rather I matched the existing files:

• The draft schema uses https://json-schema.org/draft/2020-12/schema and a "Page Schema" title, matching what's actually published at extensions.shopifycdn.com today. types/application-email.md shows draft-07 in its example, so the two are inconsistent and I followed the published artifact.
• The TOML example uses type = "admin_link" with target = "admin.app.intent.link", since page building is long-running and visual enough that navigating into the app's editor beats an inline surface. Note that types/application-email.md currently shows target = "admin.intent.render", which doesn't appear in the current docs — the render target is documented as admin.app.intent.render. Happy to open that as a separate fix if useful.

Glad to iterate on any of it, and happy to move this to an RFC discussion if you'd rather shape it there first.

[NguyenQuangHuy-Harry]

I have signed the CLA!

[adambarrus]

Hi @NguyenQuangHuy-Harry, thank you for an excellent proposal. The merchant asks you anchored this in are real ones, and the composition story with application/ad is a nice bonus.

Initial reactions on your three questions:

1. sections: keep it in the draft. The pre-fill structure is where Sidekick adds value over a bare goal string, and you've drawn the merchant-facing vs app-document-model line correctly. Expect this field to get the most scrutiny in review.
2. page_type: closed enum. Routing safety wins, and new storefront surfaces arrive rarely enough that a schema revision is acceptable.
3. publish: out of scope. "Publish the page" is an edit where status transitions to active; keeping actions to create/edit keeps the routing model simple.

One ask: consider a more specific type name. application/page is generic enough to collide with future surfaces (admin pages, checkout pages, docs). Our suggestion is application/storefront-page, which matches how your page_type enum is already scoped; open to alternatives if you have a better fit.

On the two convention divergences: good catches, both. The draft-07 example in application-email.md and the admin.intent.render target look like doc bugs rather than intent, and you followed the published artifacts correctly. A separate fix PR would be very welcome.

No need to move to an RFC; this PR is the right venue. We're reviewing the open type proposals (this and #14) and will come back with consolidated schema-level feedback.

[NguyenQuangHuy-Harry]

Thanks for the quick and detailed turnaround, @adambarrus.

Renamed to application/storefront-page — pushed. Updated the type name throughout ($id, TOML example, schema title, prose) and kept everything else as-is.

Noted on all three:

• sections staying in, understood it'll get the closest look in review.
• page_type closed enum — no changes needed, the draft already ships that way.
• publish out of scope, folded into edit + status: active — makes sense, won't add a third action.

Happy to open the separate fix PR for the draft-07 / admin.intent.render doc inconsistencies once this one settles, so it doesn't muddy this review.

Let me know if there's anything else you'd like adjusted ahead of the consolidated schema-level feedback on this and #14.

[NguyenQuangHuy-Harry]

@adambarrus — checking in on this one. Three weeks since the rename to application/storefront-page; is there anything you need from me ahead of the consolidated schema-level feedback on this and #14, and do you have a rough sense of timing for a decision?

Asking because it's now gating a shipping decision on our side. Our Sidekick action extension is built and ready to deploy, but with only shopify/product:import available in the catalog we can register the "build a page for this product" ask and nothing else — a merchant asking for a landing page with no anchoring product has no intent to route to. Rather than register an unrelated type as a placeholder, we're scoping our first release to product-anchored pages and holding the general case for this type.

Two offers if either helps move it along: I can open the doc-fix PR now (the draft-07 example in application-email.md and the admin.intent.render target) if that no longer risks muddying this review, and once our extension is live in a dev store I'm happy to share what we actually observe about how page-building asks get routed today.

[elygiux]

Would love to see this implemented too. @adambarrus Is there any update on this?

[charlesdobson]

Answered in #29 (comment). Closing this one in favour of #47 just to clean things up. It will be available soon!