Section Slot is the third Smart Container (alongside Repeater and Condition Block), but it sits at a different layer: instead of binding to data, it carves an editable placeholder the next composer fills.

A Section Slot is a named placeholder carved out of a section the section author has already designed. The section author builds the structure, layout containers, headings, decorative elements, repeaters, and decides which regions should remain open for template authors to fill. Those regions become Section Slots.

You don't build a section that is just a Section Slot. A slot only makes sense inside something, a card frame the section already drew, a row in a grid the section already laid out, an "item template" position inside a Repeater the section already bound. The slot is the opening in a designed structure, not the structure itself.

Slots are chainable and recursive: a slot can hold a slotful section, whose slots can hold more sections, all the way down.

	Section Slot	Expose as Section Prop
Exposes	A placeholder in the layout	A value on an existing component
Filled with	Any component or section	A literal value, or bound page data
Chainable / recursive?	Yes	No, a single value override

In short: slots expose a placeholder, props expose a value.

• Page authors should drop something: slot.
• Page authors should change something already there: exposed prop.

A well-designed section often uses both, slots for the variable regions, exposed props for labels and flags.

The Section Slot tile lives in the Smart Containers category of the palette while you're in section authoring mode (it's hidden in page editing). But you don't reach for it first, you reach for it after the section's shape exists.

The real authoring flow:

1. Build the section's structure first. Layout containers (Box, Row, Grid), bindings to your section's linked schema, anything that's fixed about the design, the card frame, the grid wrapper, the heading row, the call-to-action region styling.
2. Identify what's variable per template instance. Look at the structure and ask: "what here should template authors decide instead of me?" The answer is usually one or two regions, the card's media, the row's CTA, the panel's body content.
3. Drop a Section Slot into each of those regions. The slot replaces the variable content; the surrounding structure stays.
4. Label each slot via the right panel's Drop placeholder label field, "Drop a card here", "Media", "CTA". This label is what the template author sees on the canvas. It's the only contract between section author and template author for that placeholder, so make it instructive.
5. Save the section.

The order matters. If you drop a Section Slot at the top of an empty section, you've made a section that is just a placeholder, there's no design to wrap the placeholder, no reason for a template author to use this section over dropping the component directly. The value of a slot only exists when there's section design around it worth preserving across template-instance variations.

What the slot looks like to the page author depends on the label. A slot labelled "Drop a card here" renders as a dashed rectangle saying Drop a card here on the template canvas, waiting for a component or section to be dropped in.

Here's a Hero Strip section actually built this way, a Hero component owns the headline + subhead (bound to the linked schema's entry.hero.* fields), and exposes a children slot prop. Inside that slot, the section author drops a Section Slot, the only per-template-instance variation point. Everything around it (the Hero's layout, gradient background, typography, the linked-schema bindings) is locked-in section structure:

First, the Hero is dropped and selected, the right panel reveals its props, including the actions slot-type prop that is initially empty:

After dropping a Section Slot inside the Hero's slot prop, the canvas shows the dashed drop target in place:

Notice the visual integration. The Section Slot is placed inside the Hero component's children slot prop (a slot-typed prop the component itself declares, see Component schema → slot). That places the dashed drop target inside the Hero's frame, surrounded by the Hero's gradient + spacing.

If the Section Slot were instead a sibling of the Hero at the page root level, page > [Hero, SectionSlot], the slot would render below the Hero as a disconnected block. The component-slot-prop, Section Slot chain is what makes the slot read as "part of" the section rather than a separate region.

This is the canonical pattern: a registered component declares slot props for variable regions; a section composition places Section Slots inside those slot props; templates fill the Section Slots with concrete content via drag-drop.

When the section is dropped onto a page, each slot becomes a drop target with its label visible. Drop any component into it.

The slot's filled content lives on the page, not on the section. So the same section dropped twice on a page can have completely different slot contents in each instance.

Bindings inside the slot content inherit the data context surrounding the slot, if the slot is inside a Repeater, the slot's children see the current iteration item.

The pattern that comes up most often: a section that owns the layout of a list but lets the page decide what each item looks like.

The Global Field that defines the iteration source:

On a page, drop card_grid, it auto-binds to any gf_card_list field. The slot inside the Repeater renders once as a drop target. Drop a card component into it. At render time, the slot's contents repeat for every item in the list.

The real power: drop a slotful section inside another section's slot.

Build a card section with four slots:

Then on a page:

1. Drop card_grid, auto-binds to featured_products. One "Item template" slot appears.
2. Drop card into that slot. Studio scope-root matches it against the iteration item, no manual binding.
3. card's four named slots appear. Fill each with a real component.

You have three independent layers of reuse: card_grid owns the grid, card owns the card frame, leaf components own the visuals. Change any layer without touching the others.

Three things are worth knowing, they explain why slots compose the way they do and where the limits are.

Slots only fill on a template, not in the section itself. When you're authoring the section itself, the Section Slot tile renders as a labelled placeholder you can't drop into, that's intentional. Slot fills are decisions the template author makes per drop site, so they don't make sense inside the section's own canvas. The moment that section is dropped onto a template, the slot becomes a live drop target labelled with whatever placeholder text you set, ready to accept any component or section the template author drags in.

Slot fills belong to the template, not the section. When a template author drops a card into a section's slot, the card is stored on the template composition, not on the section. Drop the same section onto two different templates and each instance has its own slot contents. Edit the section later and existing slot fills aren't affected, you can rename the slot's placeholder label, reorganise the section's design, and the template-side fills stay intact. (Delete the slot entirely and its fills become orphaned, Studio cleans them up on the next template save.)

Anything can fill a slot. The slot doesn't say "only accept sections of type X" or "only images here". Any registered component or any section can be dropped. The label you give the slot is the only hint the template author has about what fits, so use it to communicate intent: "Drop a card here" / "Media" / "CTA" / "Article body".

This is the part that surprises people. When Section B is dropped into Section A's slot, the data scope flows in from outside, layer by layer:

• B's template.* is A's scope, not the template's own. If A is bound to the template's featured_card field, B's inner bindings resolve inside that field, B's own linked schema auto-binding matches against A's scope (the featured_card group), not the template's connected content type. So a card section dropped into a featured-card section's slot binds to the card-shape inside the featured-card scope.
• B inherits any Repeater scopes around it. If A is inside a Repeater, or A's slot is inside a Repeater inside A, B sees the current iteration item exactly as A would. The card section dropped inside a card-grid's iteration slot binds to the current iteration's card data.
• B can always reach the page entry as an explicit choice. If B genuinely needs the page-level entry (e.g. the page's brand_color), the Data Picker offers the page scope as an option and it always points at the outermost page entry, no matter how many slots deep B is nested.

The combination, slot fills live on the template, scope flows in from the enclosing section, and the template's connected entry is always reachable as a choice, is what lets the List + Slot pattern work without any per-section glue. The Repeater scopes each iteration to an item; the Section Slot inside the Repeater inherits that scope; any section dropped into the slot auto-binds against the item; the section's leaf components read the right fields. No wiring, no fork. The pattern is the direct consequence of slots being scope-pass-through openings.

Section	Wrapper	Slot(s)
Tabs	Repeater over tabs[]	"Tab content"
Accordion	Repeater over panels[]	"Panel body"
Carousel	Repeater over slides[]	"Slide content"
Two-column layout	No Repeater	"Left", "Right"
Hero with CTA	No Repeater	"Headline", "Subhead", "CTA"

Scenario	What happens
Rename a slot's label	Existing filled children stay bound. Empty slots show the new label.
Delete a slot	Page composers see no placeholder. Next page save cleans up orphaned slot contents.
Move a section into a Repeater after slots are filled	Children travel with it; bindings re-resolve under the new iteration.
Same section dropped multiple times	Each instance has its own slot contents.
Section deleted from the catalog	The page shows "unknown section" but preserves filled children, no data loss.

• Expose Section Props: the value-level sibling
• Auto-binding: scope-root matching that makes nested sections "just work"
• Recipe: card grid with slots