Customer Account API / 2026-04

Draft Order "components" can now
be retrieved via the Customer Account API

Starting from version 2026-04, DraftOrderLineItem to components a field has been added. Component items hanging off a parent line item (bundle contents, etc.) can now be retrieved as-is in a parent-child nested structure.

On this page
  1. What actually changed (understand in 30 seconds)
  2. What the components field is: parent-child relationship illustrated
  3. flattenComponents: comparing the two return shapes
  4. Default behavior by API version
  5. Sample query (GraphQL)
  6. 5 key points for developers
  7. 3 use cases applicable to your work
  8. One-line summary for pitches

1What actually changed

In the 2026-04 version of the Customer Account API, from a Draft Order line item you can now retrieve component line items in a parent-child structure.
Along with this, an argument to switch between "flatten components into a single list" and "nest them under the parent" flattenComponents has been added.

Before: everything flat

Parent and components were returned side by side as line items in a single flat list. From the response structure alone, you couldn't tell which was the parent and which were its contents.

2026-04: parent-child nesting

Only parent line items appear at the top level, and components hang under the components field. The parent-child relationship is reflected directly in the structure.

2What the components field is: parent-child relationship illustrated

DraftOrderLineItem.components is a field that returns the individual component line itemstied to that line item. For cases like bundle products where "a single parent item is composed of multiple contents," the contents can be expressed nested under the parent.

DraftOrder lineItems Parent DraftOrderLineItem name / quantity + components ↓ components (array of component line items) Component A: name / quantity Component B: name / quantity Component C: name / quantity
What the article shows is the relationship "returns component line items tied to a parent line item."The article does not specify which object type each component is or what fields it has.. In the sample, name and quantity are used.

3flattenComponents: comparing the two return shapes

DraftOrder.lineItems An optional argument added to the connection, flattenComponents , switches how component items are returned.

flattenComponents: false

Parent-child nesting (default in 2026-04)

node: parent line item └ components[0] └ components[1] node: another parent line item

The top-level nodes contains only parent line items. Components are traversed via each parent's components .

flattenComponents: true

Flat (legacy-compatible)

node: parent line item node: component A node: component B node: another parent line item

Both parents and components are returned as sibling nodes entries. Same behavior as versions before 2026-04.

4Default behavior by API version

API versionDefault for flattenComponentsReturn shape
2026-04 and later false Top level contains only parent line items; components are retrieved from DraftOrderLineItem.components
Before 2026-04 true Both parents and components are returned as top-level nodes (for backward compatibility)
In other words, when upgrading to 2026-04, the return shape (contents of nodes) changes unless explicitly specified. Code built on the assumption of the previous flat listing must either specifyflattenComponents: true explicitly, orcomponents migrate to an implementation that traverses it.

5Sample query (GraphQL)

Example from the article. It retrieves the parent line item's components as nested fields (assuming the default false ).

query {
 draftOrder(id: "gid://shopify/DraftOrder/1") {
 lineItems(first: 10) {
 nodes {
 name
 quantity
 components {
 name
 quantity
 }
 }
 }
 }
}
nodes Inside each element (parent) of , components just write it nested. If you want the flat legacy behavior, pass an argument like lineItems(first: 10, flattenComponents: true) .

65 key points engineers should know

CA API

1. This targets the Customer Account API

This change is about Customer Account API . It applies to contexts where "the customer themselves accesses the page," such as My Page, allowing components of draft orders to be visible. Treat it as separate from the equivalent change in the Admin API.

2. The default change is breaking

In 2026-04, flattenComponents becomes false by default. When you bump the version, the contents of nodes change to "parents only." This is the most critical checkpoint when upgrading.

false true

3. You can revert to the previous behavior via an argument

If you can't rush the migration, explicitly setting flattenComponents: true will return parents and components flat side by side just like before, even on 2026-04. It serves as an escape hatch for phased migration.

4. Use components to traverse to the constituent items

Under the default behavior, components cannot be retrieved unless you add DraftOrderLineItem.components to your query. Aggregation logic that assumes a flat structure must be rewritten as a two-tier loop: parent loop → child loop.

5. Anything not covered in the article needs verification

The full type of the component line item, the complete set of retrievable fields, behavior during pagination, and consistency with other APIs (Admin / Storefront) arenot described in this article. If you use anything beyond what appears in the sample name / quantity , verify against the actual version's schema.

73 use cases you can apply to your business

USE CASE 1

Correctly displaying "bundle contents" on the customer-facing My Page

Problem
On the draft order confirmation screen, bundle products and their components are listed flat in a single row, making it unclear to the customer which is the main item and which are the contents.
Approach
Use the Customer Account API 2026-04 default (nested), rendering parent line items as headings withcomponents as an indented child list.
Result
Order content becomes more visually clear, reducing inquiries and misunderstandings about components.
Technical notes
Parent loop → components loop, rendered in two tiers.name / quantity are fields verified in the article's sample.
Before After
USE CASE 2

Designing a "non-breaking migration" for the 2026-04 upgrade

Problem
Existing customer account implementations assume that "parents and components arrive flat in nodes." When the version is bumped to 2026-04, the default changes, risking broken display and aggregation.
Approach
① First, flattenComponents: true explicitly to bump just the API version first, → ② thencomponents gradually migrate to a nested implementation that walks .
Impact
Decouples API version upgrades from logic changes, minimizing release risk.
Technical notes
Understand the asymmetry — the default is true before 2026-04 and false from 2026-04 onward — andexplicitly setthe argument to stay safe.
USE CASE 3

Break out the parent and component items on draft quotes as separate line entries

Problem
When syncing draft orders (quotes) for B2B and similar cases to external systems, parent products and component items get mixed together and line-item aggregation units don't line up.
Approach
Fetch with the nested structure intact, treating the parent line item as the 'line entry' andcomponents as 'breakdown rows,' preserving the hierarchy when exporting to PDFs / business documents.
Impact
Component breakdowns are made explicit on quotes and delivery slips, smoothing review on the approval and accounting side.
Technical notes
Flat for aggregation (true), nested for display (false) — using flattenComponents for the right purpose keeps the logic clean.

8One-line summary you can pitch with

"With Customer Account API 2026-04, draft order component items can now be fetched as parent-child nesting.
components A new field plus theflattenComponents argument lets you switch back to the legacy flat behavior.
But the default flips to false (nested) in 2026-04, so guard upgrades by specifying it explicitly."