From 131b994b4a2f3862d83beb1cae36db2c0fd866e4 Mon Sep 17 00:00:00 2001 From: NguyenQuangHuy-Harry Date: Mon, 17 Aug 2026 10:40:30 +0700 Subject: [PATCH 1/3] Add application/page intent type (create, edit) --- types/application-page.md | 208 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 208 insertions(+) create mode 100644 types/application-page.md diff --git a/types/application-page.md b/types/application-page.md new file mode 100644 index 0000000..c2cc63a --- /dev/null +++ b/types/application-page.md @@ -0,0 +1,208 @@ +# `application/page` + +Sidekick intent type for composing or editing a **storefront page** โ€” a merchant-authored page of content and layout that an app builds and publishes to the online store. + +- **Status:** ๐Ÿšง Proposed +- **Actions:** `create`, `edit` +- **Schema:** _draft โ€” see [Draft schema](#draft-schema) below. Canonical URL to be assigned on publish:_ `https://extensions.shopifycdn.com/shopifycloud/schemas/v1/application/page.json` + +## When to register an intent for this type + +Register an `application/page` intent when your app can take a partially-specified page โ€” a goal, an audience, some products to feature, a rough section outline โ€” and either (a) build a new page or (b) open an existing one for modification in your app's editor. + +Typical examples: + +- A **page builder** registering `create` so Sidekick can hand off "build me a landing page for the summer collection launch" to the app's editor with the collection and a section outline pre-filled. +- A **page builder** registering `edit` so a merchant can ask Sidekick to "add a testimonials section to my Black Friday page" and Sidekick can deep-link into the existing page. +- A **template / theme-section app** registering `create` for "make a comparison page for these three products", where the app owns the layout and publishes to a template suffix. +- A **CRO / landing-page app** registering `create` for "spin up a landing page for this ad campaign" as the destination step after an `application/ad` intent. + +## Why this isn't covered by an existing type + +The closest existing types fall short in different directions: + +- **`shopify/product` (`import`)** carries a product GID into the app, which covers "build a page *for this product*". It cannot express a page that isn't anchored to one 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 a marketing campaign's schedule, audience, and channels. A page is frequently the *destination* of a campaign, not the campaign itself, and a merchant creates plenty of pages with no campaign behind them. +- **`application/faq`** overlaps only for the narrow case where the page *is* an FAQ. An app that builds an FAQ page should keep registering `application/faq`. + +## Apps that would register for this type + +Storefront page building is a mature, multi-vendor category on the Shopify App Store. Apps that build merchant-authored pages and would plausibly register this type include PageFly, GemPages, Shogun, Replo, EComposer, Zipify Pages, and LayoutHub, alongside theme-section and template marketplaces that publish pages on the merchant's behalf. This proposal is opened by PageFly, but the shape below is deliberately vendor-neutral โ€” it describes the page a merchant ends up with, not any one app's document model. + +## Example: register the intent + +In your extension's `shopify.extension.toml`: + +```toml +api_version = "2025-04" + +[[extensions]] +name = "build-page" +handle = "build-page" +type = "admin_link" + + [[extensions.targeting]] + target = "admin.app.intent.link" + url = "/editor/{id}" + tools = "./tools.json" + instructions = "./instructions.md" + + [[extensions.targeting.intents]] + type = "application/page" + action = "create" + schema = "./page-schema.json" +``` + +Same three rules as every other type in this catalog: + +1. **`type`** is the MIME type from this catalog. Required. +2. **`action`** is `create` or `edit`. Required. Register the same extension twice (one block per action) if you support both. +3. **`schema`** points to a local JSON Schema file that `$ref`s the canonical schema, and **must not declare `required` fields** โ€” Sidekick collects missing fields from the merchant before invoking your extension. + +## Example: the input schema + +`./page-schema.json`: + +```json +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "$ref": "https://extensions.shopifycdn.com/shopifycloud/schemas/v1/application/page.json" +} +``` + +## Fields the schema describes + +| Field | Type | Notes | +|---|---|---| +| `id` | string | The page ID in the app. Used for `edit` actions. | +| `title` | string | Page title as the merchant would name it. | +| `handle` | string | URL slug. | +| `pageType` | string | Storefront surface the page targets. See the vocabulary below. | +| `goal` | string | What the merchant wants the page to accomplish, in their words โ€” "launch the summer collection", "explain our return policy". This is the field Sidekick can fill most reliably from a merchant's prompt. | +| `sections` | array of `{type, heading, body, mediaUrl}` | A rough content outline. `type` is a loose hint (`hero`, `features`, `testimonials`, `faq`, `cta`), not a closed enum โ€” apps map it onto their own section library. | +| `products` | array of string | Product GIDs to feature on the page. | +| `collections` | array of string | Collection GIDs to feature on the page. | +| `status` | string | `draft` or `published`. | +| `seo` | object `{title, description}` | SEO overrides where they differ from `title`. | + +`additionalProperties: true` โ€” apps may pass extra fields, but Sidekick won't validate them. + +### `pageType` vocabulary + +Deliberately aligned to Shopify storefront surfaces rather than to any app's internal taxonomy: + +`home` ยท `product` ยท `collection` ยท `blog-post` ยท `page` ยท `password` + +`page` is the default and covers standalone pages including landing pages. Apps that distinguish "landing page" from "regular page" internally can keep doing so โ€” that distinction is an app concern, and collapsing it here keeps the type from fragmenting. + +**Fields deliberately left out**, since they describe an app's document model rather than the merchant-facing artifact: element/component trees, style objects, breakpoint definitions, theme or template file bindings, and revision history. + +**Fields worth discussing for inclusion:** + +- `locale` โ€” for merchants running multi-language storefronts +- `templateSuffix` โ€” where the app publishes to an Online Store 2.0 template rather than a standalone page +- `brandVoice` / `tone` โ€” a hint many builders already accept +- `referenceUrl` โ€” an existing page the merchant wants matched in style + +## Common pitfalls + +- **Declaring `required` in your `inputSchema`.** Sidekick will reject the extension at registration time. The schema describes the shape; Sidekick collects the data. +- **Treating the intent as a build API.** It isn't โ€” Sidekick navigates the merchant into your app with the intent payload pre-filled. Page generation is often slow and always subjective, so the merchant reviews and confirms in your editor before anything is published. +- **Modelling your own document format in the schema.** Two page builders will never agree on a component tree. They can agree on "a page titled X, for surface Y, featuring products Z, roughly these sections." +- **Registering both `create` and `edit` against the same handler** when `edit` needs to load an existing page and `create` doesn't. Sharing is fine; branch on `action` if the flows diverge. + +## Related types + +- **[`application/faq`](./application-faq.md)** โ€” when the page *is* an FAQ, register that instead. +- **[`application/campaign`](./application-campaign.md)** โ€” for the campaign a page is the destination of. The two compose: a campaign intent and a page intent can reasonably fire in sequence. +- **[`shopify/product`](./shopify-product.md)** โ€” for "build something from this product" where the product GID is the whole payload and the app decides the rest. +- **`application/theme-edit-task`** ([proposed](../../discussions)) โ€” for editing theme *code*. Distinct from this type: that one targets the theme's source, this one targets a merchant-authored page. + +## Open questions for reviewers + +1. **Is `sections` too app-specific to be worth carrying?** It's the field most likely to vary between builders. The alternative is dropping it and letting `goal` carry all the intent, at the cost of losing structure Sidekick could otherwise fill. +2. **Should `pageType` be a closed enum or an open string?** Closed is safer for routing; open avoids a schema revision every time Shopify adds a storefront surface. +3. **Is a `publish` action out of scope?** Every `application/*` type in the catalog today declares exactly `create` and `edit`, so this proposal follows that convention โ€” but "publish the page I made yesterday" is a plausible merchant ask, and it's a state transition rather than an edit. + +## Draft schema + +Inline draft for review โ€” no `required` anywhere. + +```json +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "$id": "https://extensions.shopifycdn.com/shopifycloud/schemas/v1/application/page.json", + "title": "Page", + "description": "A merchant-authored storefront page that an app builds and publishes to the online store.", + "type": "object", + "additionalProperties": true, + "properties": { + "id": { + "type": "string", + "description": "The page ID in the app. Used for edit actions." + }, + "title": { + "type": "string", + "description": "Page title as the merchant would name it." + }, + "handle": { + "type": "string", + "description": "URL slug for the page." + }, + "pageType": { + "type": "string", + "description": "Storefront surface the page targets.", + "enum": ["home", "product", "collection", "blog-post", "page", "password"], + "default": "page" + }, + "goal": { + "type": "string", + "description": "What the merchant wants the page to accomplish, in their own words." + }, + "sections": { + "type": "array", + "description": "Rough content outline. Apps map these onto their own section libraries.", + "items": { + "type": "object", + "additionalProperties": true, + "properties": { + "type": { + "type": "string", + "description": "Loose section hint, e.g. hero, features, testimonials, faq, cta." + }, + "heading": { "type": "string" }, + "body": { "type": "string" }, + "mediaUrl": { "type": "string", "format": "uri" } + } + } + }, + "products": { + "type": "array", + "description": "Product GIDs to feature on the page.", + "items": { "type": "string" } + }, + "collections": { + "type": "array", + "description": "Collection GIDs to feature on the page.", + "items": { "type": "string" } + }, + "status": { + "type": "string", + "enum": ["draft", "published"], + "default": "draft" + }, + "seo": { + "type": "object", + "additionalProperties": true, + "properties": { + "title": { "type": "string" }, + "description": { "type": "string" } + } + } + } +} +``` + +## Discussion history + +- Original proposal: this PR. From e013a57e3f3b3300c3fb54e9662002bed68be335 Mon Sep 17 00:00:00 2001 From: NguyenQuangHuy-Harry Date: Mon, 17 Aug 2026 11:39:58 +0700 Subject: [PATCH 2/3] Align application/page with catalog conventions - snake_case multi-word fields (page_type, media_url, blog_post) - draft 2020-12 and ' Schema' title, matching published schemas - move draft schema ahead of the field table, matching application-email.md - move rationale into the PR body per the repo PR template --- types/application-page.md | 193 +++++++++++++++++++------------------- 1 file changed, 94 insertions(+), 99 deletions(-) diff --git a/types/application-page.md b/types/application-page.md index c2cc63a..2596311 100644 --- a/types/application-page.md +++ b/types/application-page.md @@ -4,7 +4,7 @@ Sidekick intent type for composing or editing a **storefront page** โ€” a mercha - **Status:** ๐Ÿšง Proposed - **Actions:** `create`, `edit` -- **Schema:** _draft โ€” see [Draft schema](#draft-schema) below. Canonical URL to be assigned on publish:_ `https://extensions.shopifycdn.com/shopifycloud/schemas/v1/application/page.json` +- **Schema:** `https://extensions.shopifycdn.com/shopifycloud/schemas/v1/application/page.json` *(pending publication โ€” draft inline below)* ## When to register an intent for this type @@ -13,21 +13,9 @@ Register an `application/page` intent when your app can take a partially-specifi Typical examples: - A **page builder** registering `create` so Sidekick can hand off "build me a landing page for the summer collection launch" to the app's editor with the collection and a section outline pre-filled. -- A **page builder** registering `edit` so a merchant can ask Sidekick to "add a testimonials section to my Black Friday page" and Sidekick can deep-link into the existing page. +- A **page builder** registering `edit` for "add a testimonials section to my Black Friday page", where Sidekick deep-links into the existing page. - A **template / theme-section app** registering `create` for "make a comparison page for these three products", where the app owns the layout and publishes to a template suffix. -- A **CRO / landing-page app** registering `create` for "spin up a landing page for this ad campaign" as the destination step after an `application/ad` intent. - -## Why this isn't covered by an existing type - -The closest existing types fall short in different directions: - -- **`shopify/product` (`import`)** carries a product GID into the app, which covers "build a page *for this product*". It cannot express a page that isn't anchored to one 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 a marketing campaign's schedule, audience, and channels. A page is frequently the *destination* of a campaign, not the campaign itself, and a merchant creates plenty of pages with no campaign behind them. -- **`application/faq`** overlaps only for the narrow case where the page *is* an FAQ. An app that builds an FAQ page should keep registering `application/faq`. - -## Apps that would register for this type - -Storefront page building is a mature, multi-vendor category on the Shopify App Store. Apps that build merchant-authored pages and would plausibly register this type include PageFly, GemPages, Shogun, Replo, EComposer, Zipify Pages, and LayoutHub, alongside theme-section and template marketplaces that publish pages on the merchant's behalf. This proposal is opened by PageFly, but the shape below is deliberately vendor-neutral โ€” it describes the page a merchant ends up with, not any one app's document model. +- A **CRO / landing-page app** registering `create` for "spin up a landing page for this ad campaign" โ€” the destination step after an [`application/ad`](./application-ad.md) intent. ## Example: register the intent @@ -45,7 +33,6 @@ type = "admin_link" target = "admin.app.intent.link" url = "/editor/{id}" tools = "./tools.json" - instructions = "./instructions.md" [[extensions.targeting.intents]] type = "application/page" @@ -53,15 +40,17 @@ type = "admin_link" schema = "./page-schema.json" ``` -Same three rules as every other type in this catalog: +Three things to notice: 1. **`type`** is the MIME type from this catalog. Required. 2. **`action`** is `create` or `edit`. Required. Register the same extension twice (one block per action) if you support both. -3. **`schema`** points to a local JSON Schema file that `$ref`s the canonical schema, and **must not declare `required` fields** โ€” Sidekick collects missing fields from the merchant before invoking your extension. +3. **`schema`** points to a local JSON Schema file. Required. It must `$ref` the canonical schema for this type once published, and it **must not declare `required` fields** โ€” Sidekick will collect missing fields from the merchant before invoking your extension. + +The `admin.app.intent.link` target suits this type better than `admin.app.intent.render`: page building is long-running and highly visual, so navigating the merchant into the app's own editor beats rendering a focused surface inline. Apps that can do a meaningful subset of page editing in a compact UI can use the render target instead โ€” the intent declaration is identical. ## Example: the input schema -`./page-schema.json`: +`./page-schema.json` (once the canonical schema is published): ```json { @@ -70,139 +59,145 @@ Same three rules as every other type in this catalog: } ``` -## Fields the schema describes - -| Field | Type | Notes | -|---|---|---| -| `id` | string | The page ID in the app. Used for `edit` actions. | -| `title` | string | Page title as the merchant would name it. | -| `handle` | string | URL slug. | -| `pageType` | string | Storefront surface the page targets. See the vocabulary below. | -| `goal` | string | What the merchant wants the page to accomplish, in their words โ€” "launch the summer collection", "explain our return policy". This is the field Sidekick can fill most reliably from a merchant's prompt. | -| `sections` | array of `{type, heading, body, mediaUrl}` | A rough content outline. `type` is a loose hint (`hero`, `features`, `testimonials`, `faq`, `cta`), not a closed enum โ€” apps map it onto their own section library. | -| `products` | array of string | Product GIDs to feature on the page. | -| `collections` | array of string | Collection GIDs to feature on the page. | -| `status` | string | `draft` or `published`. | -| `seo` | object `{title, description}` | SEO overrides where they differ from `title`. | - -`additionalProperties: true` โ€” apps may pass extra fields, but Sidekick won't validate them. - -### `pageType` vocabulary - -Deliberately aligned to Shopify storefront surfaces rather than to any app's internal taxonomy: - -`home` ยท `product` ยท `collection` ยท `blog-post` ยท `page` ยท `password` - -`page` is the default and covers standalone pages including landing pages. Apps that distinguish "landing page" from "regular page" internally can keep doing so โ€” that distinction is an app concern, and collapsing it here keeps the type from fragmenting. - -**Fields deliberately left out**, since they describe an app's document model rather than the merchant-facing artifact: element/component trees, style objects, breakpoint definitions, theme or template file bindings, and revision history. - -**Fields worth discussing for inclusion:** - -- `locale` โ€” for merchants running multi-language storefronts -- `templateSuffix` โ€” where the app publishes to an Online Store 2.0 template rather than a standalone page -- `brandVoice` / `tone` โ€” a hint many builders already accept -- `referenceUrl` โ€” an existing page the merchant wants matched in style - -## Common pitfalls - -- **Declaring `required` in your `inputSchema`.** Sidekick will reject the extension at registration time. The schema describes the shape; Sidekick collects the data. -- **Treating the intent as a build API.** It isn't โ€” Sidekick navigates the merchant into your app with the intent payload pre-filled. Page generation is often slow and always subjective, so the merchant reviews and confirms in your editor before anything is published. -- **Modelling your own document format in the schema.** Two page builders will never agree on a component tree. They can agree on "a page titled X, for surface Y, featuring products Z, roughly these sections." -- **Registering both `create` and `edit` against the same handler** when `edit` needs to load an existing page and `create` doesn't. Sharing is fine; branch on `action` if the flows diverge. - -## Related types - -- **[`application/faq`](./application-faq.md)** โ€” when the page *is* an FAQ, register that instead. -- **[`application/campaign`](./application-campaign.md)** โ€” for the campaign a page is the destination of. The two compose: a campaign intent and a page intent can reasonably fire in sequence. -- **[`shopify/product`](./shopify-product.md)** โ€” for "build something from this product" where the product GID is the whole payload and the app decides the rest. -- **`application/theme-edit-task`** ([proposed](../../discussions)) โ€” for editing theme *code*. Distinct from this type: that one targets the theme's source, this one targets a merchant-authored page. - -## Open questions for reviewers - -1. **Is `sections` too app-specific to be worth carrying?** It's the field most likely to vary between builders. The alternative is dropping it and letting `goal` carry all the intent, at the cost of losing structure Sidekick could otherwise fill. -2. **Should `pageType` be a closed enum or an open string?** Closed is safer for routing; open avoids a schema revision every time Shopify adds a storefront surface. -3. **Is a `publish` action out of scope?** Every `application/*` type in the catalog today declares exactly `create` and `edit`, so this proposal follows that convention โ€” but "publish the page I made yesterday" is a plausible merchant ask, and it's a state transition rather than an edit. - -## Draft schema - -Inline draft for review โ€” no `required` anywhere. +## Draft canonical schema ```json { - "$schema": "http://json-schema.org/draft-07/schema#", + "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://extensions.shopifycdn.com/shopifycloud/schemas/v1/application/page.json", - "title": "Page", - "description": "A merchant-authored storefront page that an app builds and publishes to the online store.", + "title": "Page Schema", "type": "object", - "additionalProperties": true, "properties": { "id": { "type": "string", - "description": "The page ID in the app. Used for edit actions." + "description": "The page ID. Used for edit actions." }, "title": { "type": "string", - "description": "Page title as the merchant would name it." + "description": "The page title, as the merchant would name it" }, "handle": { "type": "string", - "description": "URL slug for the page." + "description": "The URL slug for the page" }, - "pageType": { + "page_type": { "type": "string", - "description": "Storefront surface the page targets.", - "enum": ["home", "product", "collection", "blog-post", "page", "password"], + "description": "The storefront surface the page targets", + "enum": ["home", "product", "collection", "blog_post", "page", "password"], "default": "page" }, "goal": { "type": "string", - "description": "What the merchant wants the page to accomplish, in their own words." + "description": "What the merchant wants the page to accomplish, in their own words" }, "sections": { "type": "array", "description": "Rough content outline. Apps map these onto their own section libraries.", "items": { "type": "object", - "additionalProperties": true, "properties": { "type": { "type": "string", - "description": "Loose section hint, e.g. hero, features, testimonials, faq, cta." + "description": "Loose section hint, for example hero, features, testimonials, faq, cta" + }, + "heading": { + "type": "string", + "description": "The section heading" + }, + "body": { + "type": "string", + "description": "The section body copy" }, - "heading": { "type": "string" }, - "body": { "type": "string" }, - "mediaUrl": { "type": "string", "format": "uri" } - } + "media_url": { + "type": "string", + "format": "uri", + "description": "An image or video to use in the section" + } + }, + "additionalProperties": true } }, "products": { "type": "array", - "description": "Product GIDs to feature on the page.", + "description": "Product GIDs to feature on the page", "items": { "type": "string" } }, "collections": { "type": "array", - "description": "Collection GIDs to feature on the page.", + "description": "Collection GIDs to feature on the page", "items": { "type": "string" } }, "status": { "type": "string", + "description": "Whether the page is published to the storefront", "enum": ["draft", "published"], "default": "draft" }, "seo": { "type": "object", - "additionalProperties": true, + "description": "SEO overrides, where they differ from the page title", "properties": { "title": { "type": "string" }, "description": { "type": "string" } - } + }, + "additionalProperties": true } - } + }, + "additionalProperties": true } ``` +No `required` fields, per the [Sidekick schema requirements](https://shopify.dev/docs/apps/build/sidekick/build-app-actions). + +## Fields the schema describes + +| Field | Type | Notes | +|---|---|---| +| `id` | string | The page ID. Used for `edit` actions. | +| `title` | string | Page title as the merchant would name it. | +| `handle` | string | URL slug. | +| `page_type` | string | Storefront surface the page targets. See the vocabulary below. | +| `goal` | string | What the merchant wants the page to accomplish, in their words โ€” "launch the summer collection", "explain our return policy". The field Sidekick can fill most reliably from a merchant's prompt. | +| `sections` | array of object | Rough content outline: `type`, `heading`, `body`, `media_url`. `type` is a loose hint, not a closed enum. | +| `products` | array of string | Product GIDs to feature on the page. | +| `collections` | array of string | Collection GIDs to feature on the page. | +| `status` | string | `draft` or `published`. | +| `seo` | object `{title, description}` | SEO overrides where they differ from `title`. | + +`additionalProperties: true` โ€” apps may pass extra fields, but Sidekick won't validate them. + +### `page_type` vocabulary + +Aligned to Shopify storefront surfaces rather than to any app's internal taxonomy: + +`home` ยท `product` ยท `collection` ยท `blog_post` ยท `page` ยท `password` + +`page` is the default and covers standalone pages including landing pages. Apps that distinguish "landing page" from "regular page" internally can keep doing so โ€” that distinction is an app concern, and collapsing it here keeps the type from fragmenting. + +**Fields deliberately left out**, since they describe an app's document model rather than the merchant-facing artifact: element and component trees, style objects, breakpoint definitions, theme or template file bindings, and revision history. + +**Fields commonly proposed for inclusion** (open an [RFC discussion](../../discussions/categories/rfc) to push for any of these): + +- `locale` โ€” for merchants running multi-language storefronts +- `template_suffix` โ€” where the app publishes to an Online Store 2.0 template rather than a standalone page +- `brand_voice` โ€” a tone hint many builders already accept +- `reference_url` โ€” an existing page the merchant wants matched in style + +## Common pitfalls + +- **Declaring `required` in your `inputSchema`.** Sidekick will reject the extension at registration time. The pattern is "schema describes the shape, Sidekick collects the data." +- **Treating the intent as a build API.** It isn't โ€” Sidekick navigates the merchant into your app with the intent payload pre-filled. Page generation is slow and subjective, so the merchant reviews and confirms in your editor before anything is published. +- **Modeling your own document format in the schema.** Two page builders will never agree on a component tree. They can agree on "a page titled X, for surface Y, featuring products Z, roughly these sections." +- **Registering both `create` and `edit` against one handler** when `edit` needs to load an existing page and `create` doesn't. Sharing is fine; branch on `action` when the flows diverge. + +## Related types + +- **[`application/faq`](./application-faq.md)** โ€” when the page *is* an FAQ, register that instead. An FAQ has a question-and-answer shape; a page has a section-outline shape. +- **[`application/campaign`](./application-campaign.md)** โ€” a page is frequently a campaign's *destination*, not the campaign itself, and most pages have no campaign behind them. The two compose rather than overlap. +- **[`shopify/product`](./shopify-product.md)** โ€” for "build something from this product", where the product GID is the whole payload. It covers product-anchored pages but can't express a page with no single anchoring resource (an About page, a campaign landing page, a multi-product comparison), and carries no page-level intent. +- **`application/theme-edit-task`** *(proposed in discussions)* โ€” for editing theme *code*. That type targets the theme's source; this one targets a merchant-authored page. + ## Discussion history -- Original proposal: this PR. +- Original proposal: *(this PR)* +- Schema v1 published: *(pending)* From 390b9cfd49ac94156575d49359cbd3a57abe07ae Mon Sep 17 00:00:00 2001 From: NguyenQuangHuy-Harry Date: Mon, 17 Aug 2026 11:42:02 +0700 Subject: [PATCH 3/3] Use api_version 2026-07 in the TOML example --- types/application-page.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/types/application-page.md b/types/application-page.md index 2596311..debdb72 100644 --- a/types/application-page.md +++ b/types/application-page.md @@ -22,7 +22,7 @@ Typical examples: In your extension's `shopify.extension.toml`: ```toml -api_version = "2025-04" +api_version = "2026-07" [[extensions]] name = "build-page"