What Is numItems in ShippingConditions?

numItems is a QuantitativeValue that limits a ShippingConditions rule to shipments containing a specified number of items.

It can define quantity bands such as one to five units, six to twelve units, or more than twelve items. The property controls when the surrounding shipping rate, time, service, or exclusion applies; it does not count products automatically.

The merchant must define what an item means in checkout. A quantity of three may represent three sellable units, three packages, or one bundle with three components. Structured conditions should follow the operational count used to quote shipping.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Define the counted unit.
• Use whole-number boundaries where appropriate.
• Match the checkout calculation.

Use the free backlink checker to find linked commerce pages before changing shipping rules.

Primary specification: Schema.org definition for numItems.

numItems is accurate when its quantity range selects exactly the shipments receiving the surrounding rule.

numItems belongs on ShippingConditions and expects a QuantitativeValue that defines the applicable item-count range.

It should not be attached directly to Product, Offer, ShippingService, OfferShippingDetails, or ShippingRateSettings. ShippingService reaches it through shippingConditions, where quantity joins destination, origin, order value, weight, dimensions, season, rate, and transit time.

Correct placement matters because a Product quantity is not the same as the number of items in a shipment. The condition should explain which complete cart or shipment cohort receives one outcome.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Start from the service.
2. Create the condition.
3. Add numItems QuantitativeValue.
4. Attach destination and outcome.
5. Validate the graph.

Review ShippingConditions for the parent model.

Correct placement makes item count one explicit constraint within a complete shipping condition.

minValue and maxValue define the lower and upper item-count boundaries for which a numItems condition applies.

A bounded tier can cover one through five items. A lower-only tier can cover six or more. An upper-only tier can cap a service at twelve items. Avoid fractional counts unless the operational system genuinely counts divisible units.

Document endpoint behavior and test the count immediately below, exactly at, and immediately above every boundary. Adjacent mutually exclusive tiers should have neither gaps nor overlaps for the same service and destination.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Choose integer count semantics.
• Set tier boundaries.
• Document inclusivity.
• Test three points per boundary.

Quantity tiers are dependable when every valid count resolves to one intentional band.

One item should mean the same operational unit that checkout uses to calculate shipping, whether that is sellable units, packages, cases, or another documented shipment count.

Cart line count and unit count are different. One line with quantity ten can represent ten items. A bundle sold as one SKU may ship as one package or several components. Subscription multiples, multipacks, kits, and split fulfillment further complicate the count.

Define the count authority before publishing numItems. Generate markup and rates from the same normalized quantity rather than recounting independently in the SEO layer.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Identify physical shippable units.
2. Define bundle behavior.
3. Exclude nonshippable items.
4. Handle split shipments.
5. Reuse the checkout count.

numItems becomes meaningful only after the store defines one consistent shipment-count unit.

Bundles, multipacks, and kits should follow their real fulfillment count rather than a guessed component total or visible line count.

A case of twelve bottles may ship as one case under a case-based rate, while a build-your-own bundle may be packed as twelve individual units. A furniture set can consist of three boxes even though the customer purchases one Offer.

Keep SKU merchandising separate from shipping operations. If different variants of the same bundle ship in different package counts, use Offer-specific eligibility or a more suitable weight and dimension condition instead of forcing one universal numItems rule.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Map each SKU to shipping units.
• Test bundle variants.
• Compare package and item semantics.
• Use weight or dimensions when more accurate.

Bundle quantity rules are truthful when they mirror how the warehouse actually prepares the shipment.

numItems, orderValue, and weight can jointly constrain one ShippingConditions rule, and all specified conditions must match for that outcome to apply.

A cart of six lightweight items worth $120 may qualify for free shipping, while six heavy items may require freight. A high item count with a low cart value can still use a different rate from one expensive item. Do not assume one constraint substitutes for another.

Build a decision matrix across count, subtotal, weight, destination, and product cohort. Test intersections rather than validating each property independently, because conflicting or missing combinations create checkout gaps.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. List every condition dimension.
2. Generate intersection carts.
3. Resolve one outcome per service.
4. Test boundary combinations.

Compare orderValue for cart-value tiers.

Combined shipping rules work when quantity, value, weight, and geography resolve together without gaps.

Quantity-based rates should attach a clear shippingRate to each numItems tier while preserving destination, service, weight, product, and cart-value context.

A merchant might charge $5 for one to five units, $8 for six to twelve, and freight above twelve. Another may offer a per-item rate. The policy should state whether quantity counts all shippable items or only eligible products in a category.

Do not publish a rate table that checkout calculates differently. If rate changes are actually driven by package weight or dimensions, model the more faithful constraint instead of using item count as a proxy.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Tie each tier to one service.
• Document eligible products.
• Validate rate formulas.
• Replace weak proxies with real constraints.

Quantity pricing is accurate when the count directly drives the rate used by checkout.

Common mistakes include counting cart lines instead of units, undefined bundle semantics, fractional or negative counts, reversed bounds, gaps or overlaps, counting digital products, stale tiers, and checkout mismatches.

Other defects include using numItems as a proxy for weight, applying one product's restriction to the catalog, and forgetting that split shipments may need separate conditions. Valid QuantitativeValue syntax cannot prove that the operational count is correct.

Quantity defects often come from a shared cart adapter. Repair the authoritative counting logic and regenerate markup rather than patching pages independently.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Extract every tier and parent.
2. Validate integer boundaries.
3. Find gaps and overlaps.
4. Compare checkout counts.
5. Repair the source.

numItems defects require quantity semantics, range, product, package, and checkout validation together.