marketplaceswalmartshipping

Walmart simplified shipping API changed: update integrations after October 15, 2026

Walmart changed its US simplified-shipping API on October 15, 2026. Remove shippingPriority dependencies and test the new optional fields.

The short version

Walmart changed the US Marketplace simplified-shipping settings contract on October 15, 2026. Integrations should stop sending or depending on shippingPriority, tolerate the newly documented optional response fields, and decide deliberately whether to use shippingMethod, customShippingRuleName or migrateEligibleOffers.

Run a read-and-write acceptance test in a safe account before the next production change. This is a Settings Management API change; it does not by itself change orders, payments or reconciliation.

What changed

Walmart removed shippingPriority from the account-level simplified-shipping create request and from the documented responses for the affected settings endpoints.

The same release added optional fields across the contract:

  • shippingMethod on account and fulfillment-center carrier configurations;
  • customShippingRuleName on fulfillment-center settings;
  • migrateEligibleOffers on the account-settings request.

The scope is the US Marketplace simplified-shipping Settings Management endpoints. Do not apply these assumptions to another Walmart market or to unrelated shipping, order or settlement APIs without checking that contract separately.

Find every dependency on the old contract

Search application code, generated clients, integration-platform mappings, request fixtures, response models and warehouse extracts for:

  • shippingPriority;
  • the simplified-shipping settings endpoints;
  • strict response schemas that reject unknown fields;
  • positional or hand-written mapping logic for carrier settings;
  • dashboards or support tools that display the removed field.

For each dependency, record the owner, environment, endpoint, operation, client or schema version and last successful production run. Include low-frequency setup and recovery jobs: a path used only when a fulfillment center is added can escape normal monitoring for months.

Change readers before they break

Response parsers should accept the newly documented optional fields without requiring them. A strict decoder that rejects unknown properties can fail even when your integration does not use the additions.

Update the reader so that it:

  1. accepts absent or present optional fields;
  2. preserves unknown fields where your integration acts as a proxy;
  3. does not infer a default shippingPriority value after the field disappears;
  4. logs schema mismatches without exposing credentials or full account payloads;
  5. stores enough request context to reproduce a failed read safely.

Test old fixtures and fresh API responses. The goal is backward tolerance where historical payloads are retained and forward tolerance for the current contract.

Remove shippingPriority from writers

Stop sending shippingPriority in account-level simplified-shipping create requests. Do not keep it as a silent fallback or retry variant: a removed property is not a recovery path.

Before deploying, inspect every code path that constructs the request. Generated models, generic serializers and saved templates can continue emitting a field after the visible application code stops setting it.

Use a narrow change. Do not combine this contract update with a wider shipping-policy redesign unless the business needs one; smaller changes are easier to validate and roll back.

Choose the new fields deliberately

Optional does not mean harmless or automatically useful.

shippingMethod

Map shippingMethod only when your operational source has a clear, current method value for the relevant account or fulfillment-center carrier configuration. Do not invent a default merely because the API now accepts the property.

customShippingRuleName

Use customShippingRuleName only when the name maps to a governed rule the operator can identify. Keep the rule name stable enough for support and audit work, and verify that changing it does not detach a fulfillment center from its intended configuration.

migrateEligibleOffers

Treat migrateEligibleOffers as an explicit migration decision. Before setting it, define which offers are eligible, save a pre-change snapshot, name an owner and specify the post-change check. Do not enable migration in a generic create or update helper without the caller choosing it.

Run the acceptance test

Use a non-production or bounded test account where available. Exercise the actual operations your integration performs:

  1. read the current simplified-shipping settings;
  2. parse responses with the new optional fields present and absent;
  3. create or update settings without shippingPriority;
  4. send each new field only in a case where its business meaning is known;
  5. read the settings back and compare the resulting state with the intended configuration;
  6. verify any affected fulfillment-center and carrier associations;
  7. confirm unrelated order and reconciliation jobs still run normally.

Save the request time, endpoint, redacted request shape, response status and resulting Walmart configuration. A successful HTTP response is not enough; the account state must match the intended shipping setup.

Deploy and monitor

Deploy readers before or with writers so production can accept the current response shape. Then watch:

  • validation and deserialization errors;
  • rejected writes;
  • missing carrier or fulfillment-center configuration;
  • unexpected offer migration;
  • support reports about changed delivery methods or shipping rules.

Observe for at least one complete run of every scheduled settings job. Keep a dated exception list for monthly or event-driven paths that have not yet executed.

The migration is complete when no production request sends shippingPriority, current responses parse successfully, every chosen optional field has an explicit business mapping, and the resulting account state passes the acceptance check.

Sources