CastleGate SKU mapping and order data rules: the mechanics behind the connection
Underneath the sync-mode and routing decisions covered elsewhere in this series, a CastleGate connection runs on a few specific mechanical pieces: a SKU map that translates in different directions depending on which way data is moving, and an order data map that tells InfiPlex which CastleGate retailer ID to use for a given order source, down to setting shipping speed by rule. This page documents those mechanics directly.
Bidirectional SKU MapOrder pushes use InfiPlex to CastleGate; inventory pulls use the reverse
Order Data MapJSON rules matching order source to a CastleGate retailer ID
Rule-Based Shipping SpeedA static shipping speed can be set per order source through the same rule set
The SKU map
One map, two directions
A single SKU map governs both directions of the CastleGate connection, but it is read differently depending on which way data is flowing. When InfiPlex pushes an order to CastleGate, the map is read in standard order: InfiPlex SKU to CastleGate SKU. When InfiPlex pulls inventory from CastleGate, the same map is read in reverse: CastleGate SKU to InfiPlex SKU. A seller maintaining this map only has to define each pair once; the direction the data needs to travel determines which side of the pair is treated as the lookup key.
The Order Data Map
Matching order source to a CastleGate retailer ID
CastleGate needs to know which retailer relationship an order belongs to, and that is handled through an Order Data Map: a set of JSON rules matching an order_source value, the marketplace or channel the order came from, to a castlegate_retailer_id. A rule can target a specific source by name, or use the wildcard ALL_ORDER_SOURCES to apply a default retailer ID to any order source not otherwise matched, with more specific per-source rules overriding the wildcard where both exist.
Rule field
What it does
order_source
The originating marketplace or channel, for example Amazon.com, or ALL_ORDER_SOURCES as a wildcard default
castlegate_retailer_id
The CastleGate retailer ID that order source should be associated with
action_type
Optional; lets a rule set a specific field on the order rather than only the retailer ID
action_data_source / static_value
Defines where that field's value comes from; a static_value supplies a fixed value regardless of order data
The same rule structure supports more than retailer ID matching. An action_type of castlegate_shipping_speed_set, combined with a static_value such as ground, forces a specific shipping speed on orders matching that rule, independent of whatever speed the order data itself might otherwise imply. This lets a seller enforce a shipping speed policy for a given order source, or for all order sources by default, directly through the mapping rules rather than through a separate setting.
Inventory pulls
Inventory pull behavior
Inventory pulls from CastleGate are configured on an interval, and each pull retrieves the full product catalog rather than only the SKUs that changed since the last pull. For a small catalog that is a non-issue; for a large one, pulling continuously (an interval of effectively zero) can create unnecessary load, which is why widening the interval is the standard recommendation as catalog size grows. The tradeoff is straightforward: a shorter interval means fresher CastleGate stock data, a longer interval means less repeated full-catalog work.
Automation
How InfiPlex maintains these mappings
InfiPlex maintains the SKU map and the Order Data Map as part of the CastleGate connection, applying the correct direction automatically depending on whether an order is being pushed or inventory is being pulled, and applying order-source-specific or wildcard rules, including shipping speed overrides, without manual intervention per order. Program page: Wayfair CastleGate integration; the routing logic that uses this data is covered in the order routing and split shipments guide.
Frequently asked
Questions, answered
The questions that come up when configuring the mechanics of a CastleGate connection.
The same map is used for both, but the direction it is read in differs: InfiPlex SKU to CastleGate SKU when pushing orders, and CastleGate SKU to InfiPlex SKU, the reverse, when pulling inventory.
Which CastleGate retailer ID an order is associated with, based on its order source, and optionally other order fields such as shipping speed, through rule-based actions.
A wildcard that applies a rule to any order source not otherwise matched by a more specific rule, functioning as the default when no source-specific entry exists.
Yes, through an Order Data Map rule using action_type set to castlegate_shipping_speed_set with a static_value such as ground, applied per order source or across all sources via the wildcard.
No. Each pull retrieves the full product catalog, not just the SKUs that changed, which is why sellers with large catalogs are advised to widen the pull interval rather than pull continuously.
It falls back to the ALL_ORDER_SOURCES wildcard rule, if one is configured; without a wildcard rule, an unmatched order source has no retailer ID to route against.
A specific order_source rule takes precedence over the ALL_ORDER_SOURCES wildcard for that source; the wildcard is the fallback, not an additional rule layered on top.
Each SKU pair needs to be defined in the map once; after that, both order pushes and inventory pulls read the correct direction automatically for that SKU without further manual work.
Setting up or troubleshooting your CastleGate SKU or order data map?
We configure CastleGate SKU maps and order data rules every week, including multi-retailer and shipping-speed overrides. Tell us your order sources and we will map the rules. Contact us, email info@infiplex.com, or call 888‑770‑0857.
Our website uses cookies to help provide the best user experience. By continuing to use this site, you consent to the use of cookies as described in our Privacy Policy. OK