A resale business sells the same inventory across many marketplaces at once. I built a cross-posting engine that describes each item once and publishes it to all of them — with retries, dedupe, and tests so it runs unattended. It is in active build for a live client; the architecture is public and runnable.
Resellers move inventory by being everywhere at once — the same jacket listed on every major marketplace. Done by hand, that means re-typing each item into each platform, then babysitting prices and "is it still listed?" across all of them as things sell.
It is repetitive, it is slow, and a missed update means selling something twice or leaving money on a stale listing. This system closes that gap — and it is a real, paid, recurring need for the client it is being built for.
One normalized model behind a uniform adapter — and rules, not guesses, on the fields that affect a sale.
An item is described a single time in a marketplace-agnostic model. Each marketplace sits behind one uniform adapter, so the orchestrator never knows or cares which platform it is posting to — adding a marketplace is a new adapter, not a rewrite.
Titles, prices, and tags are generated by pure, tested rules — never a model improvising on a field a buyer pays against. An optional LLM pass handles description prose only, behind review.
A normalized item becomes a per-marketplace listing, runs through the orchestrator, and fans out to each adapter — with a ledger keeping everything honest.
Marketplace adapters
uniform publish() interface · private
Listing ledger
what's live where → no double-posts
Partial-failure report
per-marketplace status
Reliability, idempotency, and keeping an LLM away from the fields a buyer pays against.
Every marketplace hides behind a tiny publish(listing) → id protocol. The pipeline is written once; each platform is a swappable adapter. In production those adapters are proprietary client work and stay private.
Transient failures (rate limits, timeouts) retry with exponential backoff; validation rejections fail immediately and are reported. Partial failure is a first-class outcome, not a crash.
A ledger records what is already live where, so re-running the whole inventory only posts what is missing. That is the property that makes scheduled, unattended posting safe.
The ledger is the source of truth for what's live where, keyed on (sku, marketplace) so an UPSERT can't create a duplicate. The showcase uses SQLite; the production system persists the same state in a migrated, richer schema.
The public showcase ships 14 tests over the retry state machine, transient-vs-permanent handling, idempotent skips, partial-failure reporting, and the deterministic listing rules.
This is real, paid client work. The production code and marketplace integrations are private; only a sanitized clean-room showcase with fake adapters and synthetic data is public.
Built responsibly
This is paid client work, so the production code and the marketplace integrations stay private. What is public is a clean-room showcase: the same architecture, rebuilt with fake adapters and synthetic data — no client identity, no credentials, no real endpoints.
What's next
Scheduled unattended runs, richer listing content, and per-marketplace pricing rules — then onboarding the workflow end to end for the client.
If you're doing the same multi-step job by hand and one missed update costs you money, this is the kind of system I build — engineered, tested, and yours to keep. The architecture is public and runnable. Let's talk.