[US] [HIRING] Need developer for eBay + multi-platform inventory sync API
Hello amazing people!
I've run into limitations with eBay's Developer Program and have decided to contract this job out.
I need help creating a cross-platform delisting/sync tool.
# About the project
We operate SLVR, a wholesale marketplace where sellers can list inventory. Many sellers also list the same SKU on their own website, eBay, and other third-party marketplaces. We need a clear, documented HTTP API (and supporting implementation) that we own the full source code to and can license or offer to partner sellers when they join the platform.
# The business problem
Seller X lists one physical item (one SKU / one quantity) on:
* Seller X’s home / dealer website
* eBay
* SLVR
* Other marketplaces (e.g. additional channels; exact set should be configurable per seller)
When a sale completes on any one channel, that item must be removed or marked sold everywhere else, quickly and reliably, so we never double-sell.
Concretely:
|Sale occurs on…|Required outcome|
|:-|:-|
|Home website|End/delist on eBay, SLVR, and all other connected marketplaces for that listing.|
|eBay|End/delist on home site, SLVR, and all other connected marketplaces.|
|Another marketplace|End/delist on eBay, SLVR, home site, and remaining marketplaces.|
|SLVR|End/delist on eBay, home site, and other marketplaces (align with our existing checkout flow where applicable).|
“Delist” means: end live listing, unpublish, or mark unavailable per channel rules—idempotent (safe to retry), with auditable success/failure per channel.
# What you will build (deliverables)
1. API we own
* Source in our Git repo (or repo we control), with MIT / proprietary / work-for-hire assignment as we specify - no black-box SaaS only.
* OpenAPI/Swagger or equivalent published contract for partner developers.
2. Core service responsibilities
* Registration: map a seller’s “canonical item” to external listing IDs per channel (eBay item ID, dealer site listing ID, etc.).
* Inbound “sold” events: authenticated endpoints (and/or signed webhooks) so when any channel reports a sale, the service claims that sale (prevent races) and fans out delist commands to all other channels.
* Outbound connectors (initial scope to agree in proposal): at minimum eBay + HTTP dealer site pattern; design so CAC / Heritage / others can be added as plugins.
* Retry, dead-letter, and operator visibility: per-channel status, last error, manual replay.
3. Partner / wholesale seller story
* Document how a new seller registers API keys, maps listings, and wires their site or middleware to call us (or receive webhooks).
* Example reference implementation: small Node or Python client optional but welcome.
4. SLVR integration
* Wire SLVR’s sale path (e.g. marketplace checkout) to emit the same “sold on SLVR” event into this system so eBay + home + others delist.
* Wire eBay (and other) sale notifications into SLVR so SLVR listing is ended when sold elsewhere (today this direction may be partial or missing—your proposal should close it).
5. Security & compliance
* OAuth/token handling per channel, least-privilege scopes, encrypted credential storage pattern.
* Awareness of eBay marketplace account deletion and similar obligations if we store seller tokens.
# Technical expectations (non-negotiable)
* Idempotency and concurrency control (two webhooks or double checkout must not leave inconsistent state).
* Structured logging + correlation IDs across fan-out.
* Per-channel timeouts and circuit breakers; partial failure must not silently drop channels.
* Sandbox-first verification (eBay Sandbox, etc.) before production cutover.
* Tests: unit + integration against Sandbox/stubs; CI-friendly.
Stack: Prefer alignment with our stack (Next.js / TypeScript / Supabase or agreed microservice in Node or Python with clear deployment story). We will confirm repo access and hosting (Vercel, worker, etc.) before start.
# Required experience (please address in your proposal)
* Prior eBay Sell APIs work: OAuth, Trading and/or Inventory (publish + end listing paths you will use).
* Prior multi-channel or inventory sync systems (fan-out, retries, external id mapping).
* Comfort with webhook signature verification and dealer-provided HTTP APIs (list/unlist callbacks).
# Out of scope (unless explicitly added)
* Full OMS (order management, shipping labels, accounting).
* Buy-side aggregation across marketplaces.
* ML pricing or listing optimization.
# How we will evaluate proposals
Please include:
1. Architecture diagram (ASCII or image): event in → claim → fan-out → connectors.
2. Phase 1 vs Phase 2 timeline (e.g. Phase 1: eBay + dealer HTTP + SLVR bi-directional; Phase 2: additional marketplaces).
3. Fixed price or T&M with not-to-exceed and definition of done tied to the table above.
4. 2–3 references or public samples of similar integrations (redact secrets).
5. Your availability and primary timezone.
# Intellectual property
All code, docs, and diagrams produced under this contract are work for hire / exclusive assignment to us. No reuse of proprietary seller credentials in your other projects. Third-party open-source libraries must be compatible with our licensing and declared up front.
# Budget
$500 - open to negotiation for the right person.
Looking forward to hearing from you!