Connecting your store to Amazon, eBay or Walmart usually looks like a two-week job on the plan and turns into a quarter of firefighting in practice. The listing API is rarely the problem. The trouble is everything around it: credentials that expire, feeds that succeed and then fail quietly, stock that oversells because two systems disagree, and compliance duties that only show up once you are live.

This guide is a readiness checklist for multichannel sellers in the UK, Australia and the US who are adding a marketplace, replacing a connector, or deciding whether to build the integration themselves. It covers eight areas. A condensed, printable version with a scoring sheet is available as a free PDF at the end of this article.

Short version: a marketplace integration is ready when you can answer yes to eight questions: scope, credentials, catalogue feeds, inventory, orders, limits, compliance and ownership. Any "no" is a task to finish before launch, not after.

Who this checklist is for

It is written for operations leads, ecommerce managers and technical owners at sellers who already trade online and want to sell through one or more marketplaces, or who are moving from a plug-in connector to something they control. It is not a comparison of marketplaces and it does not tell you which one to sell on. It assumes you have decided and now need to connect safely.

Each section gives you the question to ask, why it matters, and what a good answer looks like. Marketplace rules change, so confirm anything marked as a rule against the marketplace's current documentation before you build on it.

1. Scope: which channels, which flows, which regions

Start by writing down what "integrated" means for each channel. At minimum there are four flows: catalogue (listings and attributes), inventory (stock and availability), orders (receipt, acknowledgement, shipment confirmation) and post-sale (cancellations, returns, refunds, messages).

Many projects fail here because a connector is bought for listings only and the order and returns flows are discovered later. For each channel, record which flows are in scope for launch, which are manual for now, and who does the manual work.

Then record the regions. A UK seller listing on a US marketplace, or an Australian seller shipping to the UK, adds currency, tax, returns address and consumer-law questions. List the selling regions per channel and check that each flow handles them.

2. Credentials and authentication

Every marketplace API sits behind some form of authorisation, and most of it expires. Walmart's Marketplace APIs, for example, use OAuth 2.0 with a client ID and secret generated in its developer portal, and its documentation states that access tokens are valid for 15 minutes (Walmart Marketplace API introduction). A job that caches a token and reuses it will work in testing and fail after a quarter of an hour in production.

What to check:

  • Who owns the developer accounts and keys: the company, or a contractor's personal login?
  • Where secrets are stored, and who can read them.
  • Whether token refresh is automatic and tested, including what happens when a refresh fails.
  • Whether you have separate sandbox and production credentials, and a documented way to rotate them.

A good answer is that credentials belong to the company, live in a secrets store rather than in code or a spreadsheet, and rotate without downtime.

3. Catalogue and feeds

Marketplaces differ in how they accept listings, but many support bulk, feed-based setup that is processed asynchronously. Walmart's documentation, for instance, describes bulk item setup and a step for monitoring feed processing. The practical lesson is that "the upload returned 200" does not mean "the items are live".

What to check:

  • Do you track every feed or batch submission and poll for its final status?
  • Do item-level errors reach a person who can fix them, or only a log file?
  • Is there one canonical product record in your own system, with channel-specific overrides, rather than separate spreadsheets per marketplace?
  • Can you map your attributes and categories to each channel's taxonomy, and keep that mapping versioned?

A good answer is a single source of product truth, a status for every submission, and an error queue with an owner.

4. Inventory: one number, many channels

Overselling is the most expensive integration failure because it ends in cancelled orders and seller-performance penalties. It usually happens when two systems each believe they own the stock figure, or when updates arrive late.

What to check:

  • Which system is the source of truth for available stock, and is it the same one for every channel?
  • How quickly does a sale on one channel reduce availability on the others, and what is your tolerance for delay?
  • Do you hold a safety buffer on fast-moving items, and who decides it?
  • What happens to stock sent to a fulfilment network such as a marketplace warehouse? Stock held there is no longer in your warehouse count.

Our guide to inventory and order management automation for multi-channel sellers goes deeper on the architecture. For sellers who also run shops, the unified commerce integration guide covers the in-store side.

5. Orders: receipt, acknowledgement and shipment

Orders are where an integration meets your warehouse, finance and customer service. Marketplaces expect orders to be acknowledged and shipped within defined windows, and late or missing tracking updates count against you.

What to check:

  • How do you learn about new orders? Many marketplaces offer notifications or webhooks (Walmart's developer documentation lists a notifications workflow with subscriptions to event types), but a polling job should still exist as a fallback so a missed notification cannot lose an order.
  • Is order intake idempotent? The same order delivered twice must not be created twice.
  • Where do orders land: your ERP, your warehouse system, or a spreadsheet? If you run Shopify, Magento or NetSuite, see our guide on connecting ecommerce platforms to ERP without breaking your stack.
  • Is shipment confirmation, with carrier and tracking, sent back automatically?
  • Are cancellations and address changes handled, or only new orders?

A good answer is an order pipeline that survives duplicates, outages and retries, and that finance can reconcile to the marketplace's own settlement reports.

6. Rate limits and quotas

Every API throttles. The mistake is to find out in production. Amazon documents usage plans and rate limits for its Selling Partner API (Amazon SP-API usage plans and rate limits), and eBay publishes per-API daily call limits. eBay states that its default limits are designed for individuals and smaller businesses, and that higher limits are available after completing its Application Growth Check (eBay API call limits). That check verifies that your application adheres to the API licence agreement and uses the APIs efficiently.

What to check:

  • Have you estimated your call volume per day for listings, stock updates and order polling, and compared it with each limit?
  • Does your code back off and retry sensibly when throttled, rather than hammering the endpoint?
  • Do you batch where the API allows it, and avoid sending unchanged stock values?
  • If you will need higher limits, who will complete the approval, and have you allowed for the lead time?

Limits differ by API and change, so treat the figures on the marketplace's own page as the source of truth rather than a number copied from an article, including this one.

7. Compliance, privacy and consumer rules

Compliance is the section most teams leave until last, and the one with the most surprises.

Marketplace platform obligations. eBay requires third-party developers to subscribe to Marketplace Account Deletion notifications, or follow its opt-out process if they do not store eBay data, before making their first production API call. Its page states that failure to comply can result in termination of access to developer tools or reduced API access (eBay Marketplace Account Deletion). In practice that means building an HTTPS endpoint that answers eBay's verification challenge and then actually deleting the user's data when notified. That is an engineering task with a privacy purpose, and it belongs on the plan from day one.

Reviews and consumer law (UK). The UK Digital Markets, Competition and Consumers Act 2024 bans fake and misleading consumer reviews and gives the Competition and Markets Authority power to issue fines without going to court first. Law-firm commentary notes that publishers of reviews, which can include traders and online marketplaces, are expected to take reasonable and proportionate steps to prevent and remove banned reviews (Lewis Silkin analysis). If your own site displays reviews imported from marketplaces, include that flow in your review.

Privacy and data handling. Marketplace order data includes names and addresses. Decide where it is stored, who can see it, how long it is kept, and how deletion requests flow through. The rules differ between the UK, Australia and the US, so have your legal adviser confirm what applies to you. For a build-side view, see our article on data privacy compliance for ecommerce software.

We are not lawyers and this is not legal advice. The point is to put compliance on the readiness list as a named workstream with an owner.

8. Monitoring, returns and ownership

An integration that nobody watches degrades silently. Decide in advance what a healthy day looks like and how you would know it was not.

  • Alerts: failed feeds, authentication errors, throttling, orders stuck unacknowledged, and stock mismatches between systems.
  • Reconciliation: a daily comparison of orders, stock and payouts between your system and each marketplace.
  • Returns: how returns and refunds initiated on the marketplace reach your warehouse and finance. A returns and warranty hub is one way to unify this.
  • Ownership: a named person who is responsible when an API changes, a key expires or a feed breaks, and a runbook for the first hour of an incident.
  • Change tracking: someone who reads marketplace developer announcements, because deprecations and new requirements arrive on the marketplace's schedule, not yours.

Build, buy or hybrid

Once you have scored the eight areas, the build-or-buy question is easier to answer. A packaged connector suits a small number of channels with standard flows. A custom integration earns its cost when you have unusual stock logic, several channels sharing one inventory, an ERP in the middle, or a need to own the data and monitoring end to end. Many sellers land on a hybrid: a standard connector for simple channels and custom middleware for the ones that matter most.

Our API development and integration service page describes how we approach this, and the marketplace analytics page covers the reporting side. Pricing is scoped on a consultation, because it depends on the number of channels, flows and systems involved.

How to use the scorecard

The PDF companion turns the eight areas into a checklist you can complete in a working session. For each area, mark each item as done, partly done or not started. Count the "not started" items. Any area where critical items are not started, such as token refresh, order idempotency or deletion notifications, should be treated as a launch blocker. Areas that are partly done become your first sprint.

The scoring is deliberately simple. Its purpose is to start a conversation between operations, engineering and finance before go-live rather than after the first oversell.

Get the checklist

Enter your work email to download the Marketplace Integration Readiness Checklist (PDF): eight areas, a scoring sheet and a list of questions to put to any vendor or developer.

Next step

If you would like a second pair of eyes on your marketplace plan, or want to talk through build, buy or hybrid for your stack, book a consultation.