Operations · Architecture
Operations
A requirements-led guide to stock ownership, connector differences, retries and reconciliation.
Each marketplace has different records, permissions, rate limits and failure modes. Amazon merchant-fulfilled and FBA stock differ; eBay listing models can differ; Temu and TikTok Shop eligibility and API behaviour can change. Test each required connector separately.
Goal of this playbook
By the end of this guide you will have documented stock ownership, connector tests, target windows and recovery requirements.
You’ll need:
Design step
In MaxInvent, the Product table owns the stock number. Every channel (EbayListing, AmazonListing, TemuGoodsId, TiktokProduct) links back via a centralProductId mapping. Availability is computed from the pool minus buffers rather than being manually maintained per channel.
Connector-dependent
Confirm which Amazon SP-API records and fulfilment modes the connector supports. Test representative merchant-fulfilled and FBA products rather than assuming one stock flow covers both.
Pitfall
Use current Amazon documentation and observed responses for rate limits; do not hard-code an assumed universal allowance.
Connector-dependent
eBay inventory can differ by listing type. Test the actual listings on the seller account and confirm which supported API path is used for each.
Account-dependent
Confirm the supported Temu connection and test representative product mappings, stock changes, orders, retries and failures for the connected seller account.
Connector-dependent
TikTok Shop's API is straightforward, but sellers should still account for marketplace maintenance windows and transient API failures. MaxInvent schedules syncs with recovery behaviour rather than assuming every push succeeds.
Design-level — built into the platform
Require duplicate-safe updates, retry controls and visible progress. Test interrupted work and confirm that recovery does not duplicate or silently skip records.
Ongoing
Define drift as the observed time between an operational stock change and confirmed channel processing. Agree how it will be measured and investigate repeated breaches of the target.
After following every step, you should be able to verify these outcomes:
Because each marketplace only knows about its own listings. Amazon's SP-API can't tell you that eBay just sold a unit — that information has to flow through a central pool. Any architecture that uses one channel as the source of truth will drift against the others.
There is no universal fastest cadence. It depends on the marketplace, account, operation, batch size, rate limits and retries. Use dated measurements from representative tests.
Use both where available. Webhooks (event-driven push from your platform to the marketplaces) can be faster but may fail. Polling (periodic sync) is slower but can self-heal. A strong architecture is webhook-first with a polling backstop.
Two things. One: your platform should queue stock updates locally and flush them when the API recovers. Two: on other channels, you normally should not pause selling unless the failure affects the shared stock position. MaxInvent is designed to queue and recover updates, but outage handling should always be tested during onboarding.
Bundle behaviour must be tested separately. Confirm component quantities, reservations, channel mappings and recovery when a component update fails.
MaxInvent is built for UK multi-channel commerce operations. One stock and order model connects supported channels, while eligible Temu sellers and orders can use Temu shipment creation and label retrieval in dispatch.
Playbooks are educational content. For tax, legal or regulatory questions (especially around VAT), always consult a qualified adviser.