Technology•30 October 2026•8 min read•Sarah Mitchell

Syncing Amazon and Walmart Orders to Salesforce: Connector or Custom Build?

TL;DR: Prebuilt connectors handle standard Amazon and Walmart order sync into Salesforce well out of the box. Brands with custom objects, non-standard order states, or heavy payout reconciliation outgrow that mapping and need a direct API integration built around their own Salesforce org instead.

Why Amazon and Walmart order data needs to land in Salesforce cleanly

For a lot of marketplace brands, Salesforce isn't a side tool - it's the system of record. Customer service cases, fulfillment status, order history for the sales team, all of it lives there. The problem is that orders don't originate in Salesforce. They originate on Amazon and Walmart, as two different marketplaces with two different schemas, two different order-state vocabularies, and two different APIs feeding a single org that's supposed to show one clean picture.

When that sync isn't built carefully, the gaps show up in ways that are easy to miss until a customer notices first: a SKU that maps correctly on Amazon but lands as an unmatched product on Walmart, an order status that updates on the marketplace but never reaches the Salesforce case a support rep is looking at, or a payout total that doesn't reconcile against what Salesforce shows was actually sold. None of these are dramatic failures. They're quiet ones, and that's what makes the integration decision - connector or custom build - worth getting right before volume makes it expensive to fix. It's exactly the kind of order-logic-into-CRM work that YuSMP Group's Salesforce integration team gets brought in for once a brand needs the sync built directly into their org rather than bolted on through a generic mapping layer.

Getting this right matters most for brands past a certain order volume, where manual reconciliation stops being realistic and where support, fulfillment, and finance teams are all depending on the same Salesforce data being current.

How the sync actually works

Order sync to Salesforce means pulling order records from a marketplace's API and writing them into Salesforce objects - standard ones like Order and Case, or custom objects built for marketplace-specific fields - on a schedule or event trigger that keeps both systems aligned.

Amazon's Selling Partner API (SP-API) and Walmart's Marketplace API are the two source systems most brands are working with. Both authenticate over OAuth 2.0 and expose order data through authenticated REST endpoints, though the specifics of rate limits, scopes, and refresh behavior differ between them. Amazon's own Orders API reference documents what the SP-API actually exposes for order retrieval.

On the Salesforce side, that incoming order data typically lands through a named or external credential (so the integration isn't hardcoding API keys into Apex) and gets mapped into existing or custom objects. Whether new orders arrive by webhook push or by a scheduled poll, the mapping logic - deciding how a marketplace's "shipped" status becomes a Salesforce order stage, for instance - is where most of the actual engineering work sits, not in the authentication itself.

Option 1: Prebuilt connectors

A prebuilt connector is a packaged tool that already speaks both Salesforce's object model and a marketplace's API, so a brand configures field mappings instead of writing integration code from scratch. For standard order flows - a typical order lifecycle, common SKU structures, one or two marketplaces - connectors get a brand live fast and at a fraction of a custom build's upfront cost.

Where they hit a ceiling is predictable: custom Salesforce objects the connector's templates don't account for, order states that don't fit the connector's standard lifecycle, multiple brand accounts or multiple Salesforce orgs needing different logic, and reconciliation at volume that a generic mapping tool wasn't built to handle precisely.

Option 2: A custom Salesforce integration

Brands outgrow connectors for specific, recognizable reasons: a Salesforce object model built around the business's own workflows rather than a generic order shape, reconciliation logic tied to internal finance processes, or a need to feed marketplace order data directly into automation that's already running inside the org - assignment rules, approval processes, existing Apex triggers - rather than sitting next to them as a separate data source.

A custom build talks to SP-API and the Walmart Marketplace API directly and writes into Salesforce using the brand's actual object model, which means the order logic lives inside the org instead of inside a third-party connector's black box. That's also the tradeoff: more control, but the brand (or a partner) owns the maintenance as both marketplace APIs continue to change.

Connector vs. custom: what to weigh before choosing

No single factor settles this on its own, but the pattern holds across most brands: the more rows below that lean toward "custom," the sooner a connector's limits become a real cost rather than a theoretical one.

A practical rollout checklist

1. Audit current order volume, SKU complexity, and the existing Salesforce object model. Know what you're actually mapping into before picking a path.
2. Decide connector vs. custom based on the table above. Two or more rows leaning "custom" is usually the point where a connector's limits start costing more than a build would.
3. Map Amazon SP-API and Walmart API order states to Salesforce statuses before building anything. This mapping is the real engineering work - do it on paper first, not inside the integration.
4. Pilot with one marketplace before adding the second. Confirms the mapping logic works before doubling the schema differences you're reconciling against.
5. Build in reconciliation checks - payout totals against order totals - from day one. Retrofitting reconciliation after a sync is already live in production is far more disruptive than designing it in from the start.

Common sync failures and how to prevent them

A handful of failure modes account for most of the order-sync problems brands actually run into, connector or custom alike.

• Stale OAuth tokens or expired credentials. Both SP-API and the Walmart Marketplace API use token-based authorization with defined lifecycles - a sync that doesn't refresh tokens proactively breaks silently rather than loudly, and nobody notices until orders stop arriving.
• Order state drift. A marketplace status change that doesn't propagate to Salesforce leaves a support rep looking at outdated information, which is often how the gap gets discovered - by a customer, not by the system.
• Duplicate records from retried calls. Webhook retries and polling jobs that re-fetch a time window after a failure can create a second Salesforce record for an order that already synced, if the integration isn't checking the marketplace order ID as a unique key first.

Frequently asked questions

Can a no-code connector handle both Amazon and Walmart orders at once?

Most mainstream connectors support both, but coverage is rarely even - Amazon integration tends to be built first and most deeply, with Walmart mapping added on afterward. For a brand running standard order flows on both marketplaces, that's usually fine. It stops being fine once Walmart order volume or complexity catches up to Amazon's and the connector's Walmart-side mapping can't keep pace.

How long does a custom Salesforce-to-marketplace integration typically take to build?

It depends mainly on how many custom objects and non-standard order states are involved, not on marketplace count alone. A narrow build syncing one marketplace into an existing, fairly standard Salesforce object model can land in a matter of weeks. Add a second marketplace, custom order logic, and reconciliation against payouts, and the timeline stretches accordingly - the integration surface drives the schedule more than the interface does.

What happens to existing order history when switching from a connector to a custom build?

Historical order records already in Salesforce stay put - the custom build picks up new order sync going forward rather than rewriting the past. The work is in reconciling the handoff point: confirming which orders the connector synced last and making sure the new integration doesn't duplicate or skip orders in that window, which is why a brief overlap period with both systems running is common.

Do Amazon SP-API and Walmart Marketplace API work the same way for Salesforce sync?

They're conceptually similar - both expose order data over authenticated REST endpoints with their own rate limits and both use OAuth-style authorization - but the schemas, order status vocabularies, and specific endpoints differ. Code written to map Amazon order states into Salesforce objects can't be reused unmodified for Walmart; each needs its own mapping layer even inside a single custom integration. Walmart publishes its own Marketplace API documentation for brands integrating directly.

How do brands avoid duplicate orders in Salesforce when a sync job retries?

The sync logic needs to treat the marketplace order ID as a unique key and check for an existing record before creating a new one, rather than assuming every API response represents a new order. This matters most around webhook retries and polling jobs that re-fetch a time window after a failure - without an idempotency check, a single retried call can silently create a second Salesforce record for the same order.

Is a custom integration worth it for a brand selling on only one marketplace?

Usually not, unless that single marketplace already drives order volume and order-state complexity that a connector's standard mapping can't represent - custom objects, non-standard fulfillment states, or reconciliation logic tied to internal workflows. For most single-marketplace brands, a prebuilt connector covers the need well below the point where a custom build's cost makes sense.

For more on where the build-vs-buy line sits for marketplace order data in general, see our breakdown on multi-channel order management software, and for the API side of connecting marketplace data to internal systems, integrating your ERP with Seller Central.