Configure substitution preferences at order creation: specify a default substitution policy (e.g., allow shopper substitutions, prefer specific alternatives, or no substitutions) in the order payload
In your catalog, maintain a substitution mapping for key items — listing preferred alternative SKUs that share similar attributes (same brand in different size, or equivalent store-brand alternative)
When the fulfillment platform sends an order_item_replacement webhook event, extract the original item, the proposed substitute, and the price difference
If your integration requires customer approval before substitutions are confirmed, surface the proposed substitute to the customer via your app and collect approval or rejection within the platform's response window
Submit the customer's approval or rejection back to the fulfillment API; handle refund events for rejected substitutions that have no suitable replacement available
Log all substitution events for post-order analytics; use the data to refine your substitution mappings and reduce substitution frequency over time
Known gotchas
Customer approval windows for substitutions are time-limited — if the customer does not respond within the window, the platform will apply the default substitution policy configured at order creation; set reasonable defaults
Substituted items may be priced differently from the original; your payment capture flow must accommodate the adjusted order total, which may be higher or lower than the authorized amount
Not all fulfillment integrations expose a bidirectional substitution approval flow — some platforms apply shopper-chosen substitutions automatically; verify what substitution control your API access tier supports
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp