Inventory synchronisation in multichannel parts trading

Listing a part in a shop and on several marketplaces increases reach and overselling risk. A used part often has a quantity of exactly one; for new parts, supplier stock, own stock and reservations may differ. Every channel therefore needs the same available quantity from one system of record.

Architecture without competing inventories

• The ERP is the sole source for physical stock, reservations and sales status.
• Every item has an internal SKU; OE/IAM numbers, condition and fitment are master data rather than inventory keys.
• Marketplace adapters publish offers and receive sale, cancellation and return events.
• Reservations reduce availability immediately; sale and reversal are separate events.
• Scheduled reconciliation detects missed webhooks, blocked offers and quantity drift.

tapinomahub workflow and public APIs

1. Read a label through POST /scanner/label/extract-partnumbers and normalise the number with GET /parts/oe/normalize.
2. Match OE part, fitment, reference family and supersessions through GET /parts/oe/{oeNumber}.
3. Add IAM references with GET /parts/oe/{oeNumber}/aftermarket-references.
4. Prepare channel copy with GET /parts/oe/{oeNumber}/seo and, if required, GET /translation/translations.
5. Return enriched data to the ERP, which publishes through each marketplace API and remains inventory owner.
6. Reserve sales atomically in the ERP and update all other channels to zero or the new available quantity.

Failure cases to test before launch

• Two near-simultaneous sales of the same unique item
• A webhook arrives twice, late or not at all
• A marketplace rejects condition, category or compatibility
• Supplier availability disappears before confirmation
• A returned item is present but not yet sale-ready
• An OE supersession occurs while listings still use the old reference