Product feeds: connect XML and CSV

Import product knowledge from XML or CSV feeds

Choose a product feed when catalogue data is primary

Fynd can use product feeds in XML or CSV format as a knowledge source. A feed is the right option when your shop, ERP, PIM, marketplace connector, or commerce platform already exports a structured catalogue. Compared with crawling public pages, feeds give you more control over the records that are included and can be easier to keep focused on products.

Use an XML or CSV feed for product names, descriptions, SKUs, prices, availability, URLs, images, brands, categories, and other fields your export supplies. Use a sitemap crawl alongside it when blog posts or editorial buying guides are also important. Product feeds are for catalogue data; a sitemap crawl is the appropriate source for public article pages and their BlogPosting or Article JSON-LD.

Before connecting a feed, decide which system owns each product fact. If the feed is maintained by your PIM, do not also expect a manually edited product page to be the authoritative price source. Consistent ownership makes later sync results much easier to interpret.

Prepare a reliable feed

The feed must be reachable at a stable URL or available in the import flow used by your Fynd workspace. It should contain one logical row or item per sellable product or product variant, according to your chosen catalogue model. Avoid mixing product records with promotional banners, category headers, free-form notes, or HTML fragments that do not describe an item.

For a CSV feed, include a header row with clear column names. A minimal example looks like this:

id,title,description,price,availability,url,image_url
SKU-100,Travel mug,"Insulated stainless-steel mug",24.95,in_stock,https://example.com/mug,https://example.com/mug.jpg

For XML, use a consistent item structure. The exact element names can follow your exporter, but each item should expose the fields you need:

<products>
  <product>
    <id>SKU-100</id>
    <title>Travel mug</title>
    <description>Insulated stainless-steel mug</description>
    <price>24.95</price>
    <availability>in_stock</availability>
    <url>https://example.com/mug</url>
  </product>
</products>

Fynd needs readable values, not a particular marketing-feed vendor format. Nevertheless, predictable field names and consistent data types reduce ambiguity. Keep identifiers stable between exports. If a product’s identifier changes every time the feed is generated, updates may be interpreted as new products instead of changes to an existing record.

Select XML or CSV

Choose CSV when your catalogue is tabular and the data has no complex nested structure. It is straightforward to inspect in a spreadsheet and is often exported by smaller platforms and inventory systems. Use UTF-8 encoding, a consistent delimiter, and quoted values where descriptions contain commas or line breaks.

Choose XML when your provider supplies a nested feed or when products contain repeated elements, such as multiple images or category assignments. XML is common in commerce integrations and can preserve structured relationships more naturally than a flat table.

Do not convert formats solely because one appears more technical. Use the format generated reliably by your source system. A direct, stable XML feed is better than a manually transformed CSV that can fail without anyone noticing.

Map the essential fields

During setup, identify the fields that convey the product’s identity and customer-facing information. At minimum, review:

• Identifier: SKU, product ID, or another stable unique key.
• Title: the name that should appear in answers and search results.
• Description: useful product details, materials, fit, compatibility, or care guidance.
• Product URL: the destination customers can open for current details.
• Price and currency: where the feed provides them.
• Availability: for stock-oriented answers.
• Image URL: when visual product context is supported by your setup.
• Brand and category: for filtering and clearer retrieval.

Descriptions should be factual and specific. “Premium quality” gives the assistant little to work with; “water-resistant recycled polyester shell with a padded laptop compartment” is useful. Remove internal purchasing notes, supplier-only abbreviations, and fields that should not be exposed to customers.

If your feed has variants, decide whether each variant needs an individual record. Variant-level records are helpful when size, color, price, availability, or compatibility materially changes the answer. If variants differ only in an internal identifier, a parent product record may be clearer.

Add and validate the source

In the Fynd knowledge UI, add a product feed source and select XML or CSV. Provide the feed location, upload the export where applicable, and complete the field mapping. Use a descriptive source name such as PIM product export – EU. The name should identify both the owner and the market when multiple catalogues exist.

Run the first sync and review the result before relying on it. Check processed records, accepted records, skipped entries, and errors. Open a small sample spanning inexpensive products, high-value products, out-of-stock items, and products with variants. Compare the imported values with the live storefront and the original feed.

The sync UI is an operational check, not only a success notification. A feed can complete while still containing weak titles, missing prices, duplicate identifiers, or outdated URLs. Fix these issues in the exporting system whenever possible; editing the feed output manually creates a correction that the next export may overwrite.

Keep the feed current

Schedule or trigger a sync after changes that affect customer answers: newly published products, availability changes, price updates, discontinued items, renamed products, and revised descriptions. Match the sync rhythm to the business need. A catalogue that changes hourly requires more frequent updates than a seasonal range.

Publish complete feed files atomically when you can. A crawler or importer reading a file while it is being regenerated can encounter a partial catalogue. A common pattern is generating a new file and then switching the public feed URL only after generation has finished.

Keep the feed URL stable. If a provider changes it, update Fynd promptly and run a validation sync. Avoid signed URLs that expire before future synchronizations can retrieve them.

Troubleshoot common feed issues

Products are missing

Search the original XML or CSV for the product identifier. If it is absent, resolve the export filter or product publication status. If it is present, inspect whether required mapped fields are empty or malformed.

Products are duplicated

Look for duplicate IDs, parent-and-variant rows, or multiple regional exports connected as separate sources. Choose one clear identifier strategy and prevent the same catalogue from being added twice.

Text looks broken

Check CSV encoding, delimiter selection, quotation rules, and HTML escaping. For XML, validate closing tags and entity encoding. Use UTF-8 consistently.

Prices or stock are stale

Confirm when the upstream system regenerated the feed, then compare it with the last Fynd sync. Update the exporter or synchronization schedule; do not assume the feed updates itself because its URL has not changed.

Recommended operating practice

Document the source URL, feed owner, identifier field, field mappings, and expected update cadence. Review a few products after major catalogue changes. Keep a sitemap crawl for publicly available articles if you need editorial answers, and keep product feed data focused on structured catalogue facts.

Summary

XML and CSV feeds give Fynd a controlled route to product knowledge. Use stable identifiers, clear titles and descriptions, valid URLs, and a predictable export. Validate each new source with representative products, then sync it whenever customer-facing catalogue information changes.