Integration
Zuduno API and Zuduno
The same five entities as the import contract, over HTTP, for systems that would rather push than drop a file. Same staging, same preview, same reversible commit — the contract is the shape either way, so a team can start with files and move to the API without re-mapping anything.
What syncs
Four things move, and the arrow says which way.
Nothing here is maintained separately. What arrives lands on the same records every channel is served from.
- Products
- Zuduno receives.Products arrive as the canonical record, or as an update to one Zuduno already holds.
- Inventory
- Zuduno receives.On-hand by location arrives and lands on the same records the channels read from.
- Orders
- Zuduno receives.Orders and their exceptions land in the same worklist as every other source.
- Prices
- Zuduno receives.Prices arrive with the product data and become part of the record.
Markets
Where this one applies.
European Union
Markets, not marketplaces. The same channel can serve two countries whose rules differ, and readiness resolves against the country.
Readiness
What it supplies to the checks.
- Required attributes for each product type, as the source provides them
- Identifiers — GTIN, EAN, SKU, MPN — validated on arrival
- Compliance fields the market requires, carried on the record rather than in a document
- Category values, mapped to Zuduno's taxonomy on import
What it needs from you
Credentials, and nothing else.
A file your system can already produce, or an endpoint that can post one. No changes to your systems of record.
Known limitations
What this one does not do.
- It does not write anything back. A source feeds Zuduno; publishing is a channel's job.
- It does not transform your data beyond the mapping you approve at import.
- It does not accept a file that fails validation — the import is staged, reported and discarded.
Evaluate Zuduno API in your operating scope.
Confirm the data flows, markets, account permissions and readiness rules your implementation requires.