🚧 Initial release with constraints. In Checkout V2 and the widget, Routing supports a single dynamic origin per session at launch. The Headless API already supports multiple origins. Multi-dynamic-origin support for Checkout V2 is planned. This article describes what's available today, what's coming, and how to start adopting Routing for your fulfillment scenarios. Talk to your Ingrid CSM about the pieces relevant to your setup.
What is it?
Routing is the way Ingrid Checkout decides which physical locations participate in a delivery — where goods come from, where they end up, and how they get there. Routing models this as Nodes (physical locations like Warehouses, Stores, Recipients, Ombud points) connected into Routes (chains from ORIGIN to DESTINATION).
Until now, Ingrid Checkout assumed one warehouse fulfilled every order. Routing replaces that assumption with a Node-based model that can describe multi-origin scenarios — Ship-from-Store, Click & Collect, warehouse-to-store transfers, and split-cart fulfillment — all through the same API.
Routing is backward-compatible: if you have a single-warehouse setup today, nothing changes unless you choose to adopt multi-origin scenarios.
Why Routing matters
For retailers
Unlock multi-origin fulfillment at Checkout — Ship-from-Store, Click & Collect, store-to-store transfers — through a single configuration model
Per-session control over which physical locations participate in each delivery, without reconfiguring your underlying setup
No parallel system — Routing uses the same Checkout, Region ↔ Category, and OperatingSchedule logic already in place
Pick your pattern — send full Node data ad-hoc per session, or reference pre-configured Warehouses by ID, or mix the two
For shoppers
More accurate delivery options that reflect the actual fulfillment path, not a generic warehouse default
Click & Collect from real, nearby stores — pickup options come from stores that actually carry stock
Faster delivery via Ship-from-Store when a nearby store can fulfill an order quicker than the central warehouse
No change to the checkout experience — the routing decisions happen behind the scenes
How it works (high level)
Origins arrive with the session — your integration sends one or more Nodes (Warehouses, Stores) marked as ORIGIN when creating a Checkout session
Ingrid evaluates the Route — uses the sent Nodes plus your MAD configuration (Region ↔ Category relations, OperatingSchedules) to determine which delivery options apply
Delivery options are returned — each option reflects the underlying fulfillment path
Shopper selects an option — choosing the delivery option also chooses the origin (no automatic Ingrid-side selection between multiple origins)
Selected origin flows downstream — to booking, tracking, and the rest of the post-purchase journey
You can send origins Explicit (full Node data per request — useful when origins change per cart) or Partial (just a reference by external_id to a Warehouse pre-configured in MAD — useful for stable origins). Mix the two per scenario.
Common scenarios
Scenario 1 — One template Warehouse, real Warehouses sent per session
Best for: retailers with many warehouses or warehouses that change frequently (acquisitions, seasonal sites, WMS-sourced lists).
You keep one MAD-configured Warehouse as a template. Your integration sends the real Warehouse data per session — address, OperatingSchedule, contact details. Ingrid uses what you send to calculate delivery options.
Scenario 2 — Click & Collect (in-store pickup)
Best for: retailers offering in-store pickup as a delivery option.
The store IS both the ORIGIN and the DESTINATION (a one-hop Route). Your integration sends the stores carrying stock for the cart. Shoppers see in-store pickup options for those specific locations.
Scenario 3 — Ship-from-Store
Best for: retailers using local store inventory to fulfill nearby online orders (typically fashion, electronics, multi-channel).
Your integration sends stores as ORIGIN nodes. Ingrid returns delivery options scoped to each store's region. The shopper's delivery promise reflects the actual shipping distance from the store, not the central warehouse.
Scenario 4 — Warehouse-to-store transfer
Best for: retailers replenishing store inventory or shipping to a store for shopper collection.
The Warehouse is the ORIGIN, the store is the DESTINATION. Useful for bulky items, replenishment, or fulfilling Click & Collect when the chosen store doesn't carry the item.
Scenario 5 — Split-cart with different origins per group
Best for: carts mixing items from different fulfillment sources in the same checkout.
You group cart items and assign different origins per group. Ingrid generates delivery options for each group independently, scoped to each group's origin.
Which scenarios fit you?
You want to offer... | What you need |
Multi-warehouse fulfillment with dynamic origins | Routing with Explicit or Partial pattern; MAD-configured Warehouses or per-session data |
Click & Collect (in-store pickup) | Routing with Explicit Locations → Locations pattern; in-store delivery method enabled |
Ship-from-Store | Routing with stores sent as ORIGIN; standalone SFS Region + artificial Warehouse workaround (until |
Warehouse-to-store transfers | Routing with Warehouse ORIGIN + store DESTINATION |
Split-cart fulfillment | Routing with per-group origins in the session payload |
Single-warehouse delivery (no change) | Your existing setup keeps working — no action needed |
How to enable Routing
Confirm the right pattern with your Ingrid CSM — Explicit, Partial, or hybrid
Configure Warehouses in MAD — set
external_id, Roles, and Region ↔ Category relationsFor Ship-from-Store — set up a standalone SFS Region + artificial Warehouse mapping (current workaround pending
node.tagssupport)Update your session create payload — include the
originsarray with the Node objects relevant to your scenarioTest with your CSM — verify delivery options returned match the expected fulfillment paths
Detailed setup guidance, including API request shapes and configuration steps, will live on developer.ingrid.com (publishing soon). Your CSM can share the working setup recipes in the meantime.
What's available today
Node-based session payload — send origins via the
originsarray in session createExplicit and Partial integration patterns — full Node data ad-hoc, or reference by
external_idto MAD-configured WarehousesMixed origins — Warehouse + stores in the same session, evaluated independently
Click & Collect via one-hop Routes — ORIGIN = DESTINATION supported
Split-cart per group — different origins per cart group
Per-Node
handofftimes — override OperatingSchedule per session when neededBackward compatibility — single-warehouse setups keep working without change
What's planned next
Multi-dynamic-origin per session in Checkout V2 / widget — the Headless API already supports multiple origins; this brings the same to Checkout V2 and the widget
node.tagssupport — will enable Ship-from-Store categories within a single Region, retiring the standalone-Region + artificial-Warehouse workaroundOrigin decision logic — automatic selection based on stock levels or proximity is being explored (currently the integrator or shopper makes the explicit choice)
Expanded Routing-specific analytics — fulfillment-path distribution, multi-origin adoption metrics
FAQ
Q: Will my existing single-warehouse setup change when Routing ships?
A: No. Routing is backward-compatible. If you don't adopt multi-origin scenarios, your Checkout continues to work exactly as before.
Q: Do I need to be on Checkout V2 to use Routing?
A: Yes. Routing requires Ingrid Checkout V2 or the Headless Checkout API.
Q: Can I send multiple origins per session?
A: Yes, via the Headless API — it supports multiple origins per session. When several origins generate similar delivery options, you deduplicate them at the integration layer. Checkout V2 and the widget currently support a single dynamic origin per session; multi-origin support for them is planned.
Q: Does Ingrid pick which store fulfills when I send a list of stores?
A: No, not in the initial release. The selection is explicit — either the integrator decides via the order of items in the origins array, or the shopper chooses at session complete. Automatic decision logic (stock-based, proximity-based) is under exploration.
Q: How do I configure Ship-from-Store?
A: Currently via a standalone Region dedicated to SFS, plus an "artificial" Warehouse that stores map to via external_id. This workaround will be retired once node.tags support ships, allowing SFS categories within a single Region.
Q: Can I send a Warehouse and stores together as origins?
A: Yes. Mixed origins in a single session are valid. Each origin is evaluated independently based on whether its external_id matches a configured Warehouse.
Q: What about deduplication when multiple origins generate similar delivery options?
A: Multiple origins generating multiple options is expected behavior. If the retailer experience requires deduplication, use filter rules at the integration layer.
Q: How will my booking and tracking change with Routing?
A: Once a delivery option is selected at session complete, the chosen origin flows through to booking and tracking just like any other origin. Booking and tracking integrations don't need separate Routing-specific changes.
More information
Routing is being delivered in phases. For timing on the pieces relevant to your setup — including multi-dynamic-origin support, node.tags, and Routing-specific analytics — talk to your Ingrid CSM.
Detailed developer documentation, including API request shapes, response handling, and code samples, will publish on developer.ingrid.com.