Selling on a marketplace and on your own site at once

Selling on a marketplace and on your own website at once works when both channels read and write one shared stock and order record; it breaks when each keeps its own. The fix is a single source of truth, an idempotent sync layer, and a daily reconciliation job that catches the drift batch imports leave behind.

Key Takeaways

• Two channels need one stock and order record. Two separate records guarantee an oversell eventually, usually on a weekend.
• Marketplace APIs are eventually consistent — a webhook that arrives forty seconds late can still sell the last unit you own.
• Idempotency is not optional. Store the marketplace's order ID with a unique constraint, or a retried webhook creates a second order.
• Batch CSV imports are the weakest link. They overwrite rather than merge, and they know nothing about what sold in the last hour.
• A daily reconciliation that compares counts per SKU catches drift no human will ever notice by eye.
• Below a handful of orders a day, manual updates are genuinely fine. Don't build a sync layer you'll have to operate.
• You rent the customer on a marketplace and own them on your own site. That asymmetry should decide where you invest.

What does selling on two channels actually involve?

Two channels means two catalogues, two order streams and one physical shelf. Every item you sell exists once in the real world and twice online, so price, stock, description and tax have to reach both. Most failures come from treating those updates as separate jobs instead of one write to a shared record.

In practice you end up maintaining three things: a product record, an availability number, and a mapping between your SKU and the marketplace's listing ID. That mapping is the piece teams forget, and it's the piece every sync breaks on first.

Why do marketplace stock and website stock drift apart?

Drift appears because each channel updates on its own clock. A marketplace webhook arrives late, a nightly CSV import overwrites everything, and your storefront decrements stock the moment a cart is paid. Between those events the same unit looks available in two places, and whoever pays first takes it.

Three mechanisms do most of the damage. The first is last-write-wins: a bulk import written at 02:00 carries yesterday's numbers and cheerfully undoes a sale that happened at 23:50. The second is eventual consistency — marketplaces queue their events, so a "sold" notification can land a minute after a customer on your own site bought the same item. The third is rate limiting: if your sync job gets throttled and retries later, the interval between the two channels' views of reality stretches from seconds to hours.

None of this is exotic. It's the normal behaviour of distributed systems, and the reason a shared ledger plus a reconciliation pass beats optimistic syncing every time.

When do you actually need a sync layer?

You need a sync layer when the same SKU sells on both channels faster than a human can correct it. As a rough line, if a popular item moves more than a few units a day across both, manual updates will eventually sell something you don't have, and the cost of that is a cancelled order and a rating drop.

You don't need one when stock is effectively infinite (digital goods, made-to-order), when the two channels sell disjoint ranges, or when volume is low enough that one person checks twice a day. Building an integration you then have to monitor, patch and pay for is a real cost — take it on when the oversell risk is bigger than the maintenance.

How do you set up a second sales channel without duplicating work?

You set up a second channel by making the marketplace a client of your system, not a parallel one. Your store owns the product record and the stock number; the marketplace gets told what changed. The steps below are the order that avoids rework.

1. Pick the system of record. Usually your own store, because you control it. Every product gets one internal SKU that never changes.
2. Map listings to SKUs. Store the marketplace's listing and variant IDs against your SKU in a table you can query. Without this, no sync can be trusted.
3. Create the shared order table with a uniqueness rule on the channel plus the external order ID, so a retried webhook cannot create a duplicate.
4. Subscribe to marketplace events. Most platforms offer webhooks for order and cancellation events; where they don't, poll on a short interval and store the last-seen timestamp.
5. Put the events on a queue. Validate the signature, then enqueue. Do the stock write in a worker, not in the webhook request — marketplaces time out and retry, and retries are where duplicates come from.
6. Push stock outward, not inward. Treat the marketplace's stock figure as a copy. Only your ledger decrements, and only in one transaction per order.
7. Add a nightly reconciliation job. Compare per-SKU availability on both sides and alert on any difference above zero.

CREATE TABLE orders (
  id                BIGSERIAL PRIMARY KEY,
  channel           TEXT NOT NULL CHECK (channel IN ('marketplace','own_site')),
  external_order_id TEXT NOT NULL,
  sku               TEXT NOT NULL,
  quantity          INTEGER NOT NULL CHECK (quantity > 0),
  created_at        TIMESTAMPTZ NOT NULL DEFAULT now(),
  UNIQUE (channel, external_order_id)
);

That unique constraint is the single cheapest safeguard you can add. When a marketplace sends the same order twice — and it will — the second insert fails loudly instead of shipping twice.

If your store runs on WordPress, this is mostly a question of how much of the catalogue you keep in WooCommerce versus a separate system; our guide to WordPress versus a custom website covers that trade-off, and our services include building the integration layer when the two systems don't want to talk.

How do you verify the two channels agree?

You verify by comparing counts, not by eyeballing listings. A reconciliation query that joins your ledger against the last stock figure pushed to the marketplace will show every SKU where the two disagree, and it takes seconds to run on any catalogue under a few hundred thousand rows.

Run it nightly, and again after every bulk import. Alert on any non-zero difference and on any SKU where the marketplace reports stock but your ledger reports zero — that combination is the one that becomes an oversell. Log the comparison result even when it's clean, so you can show an auditor or a marketplace dispute exactly what your numbers were on a given day.

What breaks first in production, and how do you debug it?

The first failure is almost always overselling on the last unit of a fast-moving SKU, followed by duplicate fulfilment from a retried webhook. Debug in this order: check the ledger transaction log for that SKU, then the webhook delivery log, then the marketplace's stock figure, then your cache.

• Two orders, one unit. Look for a webhook that arrived after the sale but before the stock write committed. Long transactions and slow workers widen that window.
• Duplicate orders. A retry with no idempotency key. Check whether the second insert hit the unique constraint, and whether your handler logged it as an error instead of ignoring it.
• Stock that never comes back. Usually a cancellation event you never subscribed to, or one that failed signature validation and was silently dropped.
• Prices that disagree. A scheduled import overwriting a manual change. Timestamp your imports and refuse to apply any row older than the last known change.
• Everything stalls at once. Token expiry or an API rate limit. Marketplaces expire credentials without much warning, so alert on repeated 401s rather than waiting for a customer to complain.

The fix pattern is the same each time: move the write into a single transaction, make it idempotent, and alert on the difference instead of trusting the sync to be perfect.

What does running two channels cost you?

Two channels cost less in licences than in attention. Expect a marketplace commission on every sale, occasional listing or subscription fees, and — if you use a connector — a monthly charge that scales with order volume. Those are the visible numbers, and the vendor's own pricing page is the only place to confirm them.

The invisible cost is engineering time. Somebody has to own the mapping table, rotate API credentials, watch the reconciliation alerts and fix the SKU that stopped syncing three weeks ago. Budget a few hours a month in a quiet period, and considerably more the first time you add a new marketplace or change your stock model.

What should you check on security and account ownership?

Treat marketplace API credentials as production secrets. Store them in a secret manager or your platform's environment configuration, never in a theme file or a repository. Verify webhook signatures before you act on a payload, and reject anything that fails rather than logging and continuing.

Grant the narrowest scope the integration needs — order read and stock write, not account administration. And make sure the marketplace account, the domain and the hosting are registered to the business, not to a former contractor's personal email. We've been called in more than once to recover an account nobody could log into, and it is a slow, unpleasant process. Our frequently asked questions cover how we handle credentials and handover.

What mistakes do teams make most often?

The most common mistake is syncing stock in both directions. When the marketplace can also write your availability, you get feedback loops where one correction triggers another, and the numbers oscillate. Pick one writer — your ledger — and make the other side read-only for stock.

Second is trusting a bulk import to be authoritative. A CSV is a snapshot, not a source of truth, and applying it blindly undoes live sales. Third is testing the integration with one order on a quiet Tuesday and assuming it holds on a campaign day, when hundreds of webhooks arrive at once and your worker pool is the bottleneck.

A realistic scenario

A Kathmandu retailer sells outdoor gear on a regional marketplace and through their own store. They started with manual updates: list on both, adjust stock when an order comes in. It worked at ten orders a week. During a festival promotion it didn't — one tent sold twice within four minutes, and the marketplace cancelled the second order, which cost them the seller rating they'd spent a year building.

The fix wasn't a new platform. They kept their store as the system of record, added a mapping table between SKUs and marketplace listings, moved order handling onto a queue with a unique constraint, and started a nightly reconciliation that emails a single number: how many SKUs disagree. Oversells stopped. Nobody has touched the integration in months except to rotate a token.

Which approach fits your business?

Choose the setup that matches how fast your stock actually moves, not the one that sounds most advanced. A shared ledger is the right answer for most retailers doing steady volume on both channels; manual updates remain perfectly rational below a handful of orders a day.

Approach	Stock accuracy	Operational load	Best fit
Marketplace only	High — one system owns it	Low	Testing demand before building a brand site
Own site only	High	Medium — you drive all the traffic	Businesses with an audience or B2B contracts
Both, shared ledger	High with daily reconciliation	Medium to high — one more system to run	Retailers selling steadily on both channels
Both, manual updates	Low on busy days	Low until it fails	Very low volume, low-variance stock

If you already have a store and you're adding a marketplace, the integration work is closer to plumbing than product development — which is why it's often worth doing properly once rather than patching monthly. A look at how we've approached business platforms in Nepal shows the shape of that work.

In short

• One ledger, one writer. The marketplace gets a copy of your stock, never authority over it.
• Idempotency first — a unique constraint on channel plus external order ID costs nothing and prevents double fulfilment.
• Queue the webhook, write in a worker, and treat retries as normal rather than exceptional.
• Reconcile nightly and alert on differences. The job that finds drift is worth more than the sync that assumes there is none.
• Below a few orders a day, keep it manual and spend the money on marketing instead.

People also search for

• What a web development quote should actually break down
• WordPress or a custom website for an online store
• Connecting a website to accounting and inventory software
• Who owns the website code and the accounts
• Should you rebuild the site or fix what you have
• What a cheap website really costs over three years
• What scalable actually means for a small retailer

If your stock numbers on the marketplace and on your own site no longer agree, or you're about to add a second channel and would rather not discover the problem during a promotion, talk to our team. We build these integrations in your accounts and repositories, and hand over something your own staff can operate — you can see the wider range of what we do first if you'd like context before the call.