I’d like to propose a feature enhancement for the Section Rendering API that would significantly improve the developer experience for app developers working with theme app extensions.
Current Limitation: The Section Rendering API currently only supports rendering theme sections from the /sections directory. While it can render sections containing app blocks that have been added via the theme customizer, there’s no way to directly render app blocks or theme app extension content in isolation.
Proposed Feature: Extend the Section Rendering API to support rendering app blocks and theme app extensions directly. This could work similarly to the existing API:
GET /?section_id=<app-block-id>
// or
GET /?app_block_id=<app-block-id>
Use case:
Currently, I am requesting full page content, and it would be much more efficient if I simply made a request to only my app block content.
Thanks @KyleG-Shopify, I am happy to provide more details if the theme needs it. Especially to support 2048 variants, this will be very important for the performance.
This would be extremely useful if allowed rendering app embeds as well somehow. Cart drawer apps could hugely benefit from this. Cart drawer apps are forced into app embeds due to their nature, so app embeds should also be considered for this feature.
Just for clarification for my case I also use app embeds but in the end app embed also being rendered as a app block on the page. So in my case I also need Section rendering api for App embeds not specificly for app blocks.
Plus one from a Shopify app maker. We ship Better Related Blog Posts as a TAE app block, and the inability to call Section Rendering API against app blocks is the single biggest workaround we maintain.
Today the only stable pattern is exposing a custom app proxy endpoint that returns rendered HTML, then injecting it client-side; that bypasses Shopify’s renderer entirely and means we lose locale resolution, dynamic sources, and any conditional Liquid that depends on the request context. A merchant on Horizon with locales configured will get the wrong language back unless we round-trip to the proxy with the locale code, which is fragile.
Native fallback for anyone reading: render your block server-side on initial Liquid load and only refresh via app proxy on user interaction; do not try to mount it in cart drawers or other section-rendered contexts.