XML / YML
Import catalogue-style XML and YML documents with repeatable offer nodes.
When to use it
A practical fit for your existing workflow.
Commerce platforms and catalogue tools that already publish XML product feeds.
Input contract
Fields and structure
Use stable field names and meanings across every refresh. Legend normalizes the values, but the source contract should not drift silently.
Required or expected
sku or offer@idtitle or namepricecurrencyproduct_url or url
Recommended fields
gtin or barcodebrand or vendoravailablecategorypicturedescriptionsize
Supported variations
- LQRS Feed XML container
- YML catalogue container
- Mapped custom offer node
- Attributes and child elements
Copyable example
XML feed
Replace the demonstration values with your own catalogue data. No customer, order, or payment data belongs in an inventory feed.
XML
<lqrs-feed version="1">
<offers>
<offer>
<sku>DEMO-001</sku>
<title>Legend Demo Single Malt</title>
<gtin>5010327000142</gtin>
<price>39.50</price>
<currency>GBP</currency>
<product_url>https://merchant.example/products/demo-001</product_url>
<stock>30</stock>
</offer>
</offers>
</lqrs-feed>From source to live offer
Connection workflow
Every route uses the same quality gates before an offer becomes public.
Identify the repeating offer element.
Map attributes and child elements to Legend fields.
Validate identifiers, prices, and record count.
Schedule the feed and monitor stale or missing offers.
Before publication
Validation checklist
These checks keep bad prices, stale stock, and uncertain product matches out of the public marketplace.
- The XML must be well formed and use a stable offer container.
- External entities are not required or trusted.
- Currency and price are validated per offer.
- YML compatibility uses the yml_catalog/shop/offers/offer path.
Other connection paths