XML Product Import and Supplier XML Integration Service

What is XML product import and what does supplier XML integration do?

XML product import is the controlled transfer of a product catalog from a supplier, manufacturer, distributor or another data source into an e-commerce system. The feed can include product name, SKU, barcode, category, brand, description, purchase or sale price, stock, VAT, image URLs, technical attributes and variation data.

The critical work is not simply opening the XML file. A production integration must map fields to the target data model, avoid creating duplicates, update stock and prices safely, preserve category and variation relations and record errors for later review.

A one-time import and an ongoing integration are therefore different scopes. A one-time job may only load today's catalog. A scheduled integration can check the source again, add new products, update existing records and react when supplier data changes.

At Eka Sunucu, the implementation is planned around the existing software. For open or modifiable codebases we can develop a dedicated import layer. For closed SaaS platforms, we evaluate official API, app and import capabilities instead of promising source-code changes that are not possible.

• One-time XML product import
• Scheduled stock and price synchronization
• Automatic detection and creation of new products
• Matching by SKU, barcode or supplier ID
• Category, brand, attribute and variation mapping
• Remote image linking or local image download
• Margin, VAT, currency and rounding rules
• Error logs, failed-product reports and retry logic

What does a sample XML product tree look like?

Every supplier may use a different XML schema. The sample below only demonstrates a common catalog structure. Your real field names may be completely different; the important part is identifying which node represents which piece of product data.

The example contains two EKA products. The root node is products, each record is held in a product node and its data appears in child nodes. During integration we first identify the repeating product node and then map each child field to its target.

<products>
    <product>
        <name>EKA Pro Oyuncu Bilgisayarı</name>
        <category>Bilgisayarlar > Masaüstü Bilgisayarlar</category>
        <productCode>EKA-PC-001</productCode>
        <barcode>8690000000001</barcode>
        <brand>EKA Teknoloji</brand>
        <quantity>25</quantity>
        <price>34999.90</price>
        <tax>20</tax>
        <description>EKA Pro serisi yüksek performanslı oyuncu bilgisayarı.</description>
        <images>
            <image>https://ornek.com/eka-pc-001-1.webp</image>
            <image>https://ornek.com/eka-pc-001-2.webp</image>
        </images>
        <variants>
            <variant>
                <option name="RAM">32 GB</option>
                <sku>EKA-PC-001-32</sku>
                <stock>12</stock>
            </variant>
        </variants>
    </product>
    <product>
        <name>EKA Mekanik Oyuncu Klavyesi</name>
        <category>Bilgisayar Aksesuarları > Klavye</category>
        <productCode>EKA-KLV-002</productCode>
        <barcode>8690000000002</barcode>
        <brand>EKA Teknoloji</brand>
        <quantity>80</quantity>
        <price>2499.90</price>
        <tax>20</tax>
        <description>RGB aydınlatmalı EKA mekanik oyuncu klavyesi.</description>
        <image1>https://ornek.com/eka-klv-002-1.webp</image1>
        <image2>https://ornek.com/eka-klv-002-2.webp</image2>
    </product>
</products>

What is XML field mapping? Do name, title and urun_adi mean the same thing?

There is no universal requirement that a product name must be stored in a field called name. One supplier may use name, another title, urun_adi, ProductName or model_name. The same variation exists for stock, price, barcode and category fields.

Integration creates an explicit mapping between source fields and target fields. For example salePrice can map to the store's sale price, stock to quantity and sku to the internal product code.

Mappings can be hard-coded for a stable single feed or exposed in an admin screen when several suppliers need to be managed. The best approach depends on how often feed structures change and who will maintain the integration.

<urun>
    <urun_adi>EKA Kablosuz Mouse</urun_adi>
    <stok_kodu>EKA-MOU-003</stok_kodu>
    <stok>150</stok>
    <satis_fiyati>899.90</satis_fiyati>
</urun>

<item>
    <title>EKA 27 İnç Gaming Monitör</title>
    <sku>EKA-MON-004</sku>
    <stock>32</stock>
    <salePrice>7499.90</salePrice>
</item>

How is an XML catalog imported into an e-commerce site step by step?

A safe import does not begin by writing tens of thousands of rows directly into production. The source is validated first, sample products are inspected and mandatory fields are identified. The store's product, category, brand and variation model is then analyzed.

A pilot import follows. A small group of products is used to test product creation, image processing, category assignment, pricing, stock updates and duplicate prevention when the job is run again.

Before production sync begins, the update policy for each field should be explicit. If store managers manually edit descriptions, for example, the integration can be configured to update only stock and price instead of overwriting editorial content.

• Validate XML access and format
• Identify the repeating product node and unique key
• Map source fields to target product fields
• Define category and brand mappings
• Analyze variation grouping and combinations
• Run a pilot import
• Test duplicate, price, stock, image and encoding behavior
• Use batch/queue processing for large catalogs
• Configure cron intervals and logging
• Verify the first production synchronizations

How are duplicate products prevented?

One of the most important design choices is the unique product key. Product names are not reliable identifiers because titles can change and different products may share the same name. A stable supplier ID, SKU or barcode is usually preferred.

At each synchronization, the target store is searched by this key. If no record exists, a new product is created. If a record exists, only the fields allowed by policy are updated. This prevents the catalog from growing with duplicates every time cron runs.

If supplier codes can change, a separate mapping table may be required. Multi-supplier catalogs, variant-specific SKUs and products without barcodes also require project-specific matching rules.

How can XML stock and price updates be automated?

After initial import, stock and price synchronization is usually the most frequent operation. When the supplier feed changes, the job reads the source again, finds the related product by its unique key and updates the selected fields.

There is no single correct schedule for every project. Fast-changing stock may justify frequent checks, while scanning a huge slow-changing feed every few minutes may waste server and supplier resources. The interval should reflect catalog size, supplier refresh frequency and overselling risk.

Stock buffers can be applied. For example, supplier quantities below three can be exposed as zero in the store. A catalog can also cap visible stock or combine selected warehouse quantities.

Pricing does not need to copy the source price directly. Margin, fixed fees, VAT, currency conversion and rounding can all be applied as a rule chain.

Can margin, VAT, currency and rounding rules be applied to XML prices?

Yes. The source price can be treated as raw input and transformed before it becomes the store price. A 25 percent margin, VAT calculation and a final psychological-price rounding rule can be applied sequentially.

If one margin is not suitable for every product, price bands can be used. Products below one threshold can receive a higher percentage while expensive products receive a lower one. Rules can also vary by brand, category or supplier.

For foreign-currency feeds, the exchange-rate source and refresh frequency must be defined. If the supplier already provides a reliable local-currency price it may be preferable; otherwise USD or EUR prices can be converted according to an agreed rate source.

• Percentage-based margin
• Fixed amount addition or deduction
• Category / brand / supplier-specific rules
• Tiered margins by price range
• VAT-inclusive or VAT-exclusive calculations
• USD / EUR to TRY conversion
• Minimum selling price
• Psychological rounding such as 899.37 → 899.90
• List price and discounted price generation
• Separate handling of supplier campaign prices

How are categories, brands, attributes and variations mapped?

Names and prices are usually the easy part; category trees and variations create most of the integration complexity. A supplier category such as 'Computers > Peripherals > Keyboards' may correspond to 'Technology > Gaming Gear > Keyboards' in the store.

A mapping table links the source category to the target category. Automatic category creation is possible, but uncontrolled creation can generate hundreds of unwanted or duplicated categories, so controlled mapping is often safer.

Variations such as color, size, shoe size or capacity may be represented as combinations below a parent product. If each variation has its own SKU, barcode, price and stock, these values must be converted to the target platform's own variation model.

How are product images from XML handled?

Most XML feeds contain image URLs rather than the binary image itself. The integration can either keep the remote URL where the platform supports it or download the file into the target media library.

For local downloads, content type, file size, timeout and failed-download logging should be controlled rather than trusting the extension alone. URL or content hashes can prevent the same image from being downloaded on every synchronization.

Image order can be preserved so the first image becomes the cover and the remaining URLs become gallery media. The parser can also handle repeated image nodes or supplier-specific delimited image fields.

How are XML feeds with 10,000, 50,000 or 100,000 products processed?

Loading a very large XML file entirely into memory can consume excessive RAM. SimpleXML is convenient for small and medium feeds, while streaming readers such as XMLReader are often more appropriate for very large catalogs because product nodes can be handled sequentially.

Large imports should not depend on a single browser request remaining open until completion. Batch, CLI, cron or queue processing can handle a defined number of products per run and persist progress so an interrupted job can continue.

Performance is not only about XML size. Database lookups, category checks, image downloads, variation creation and remote requests dominate total runtime. Proper indexes, reusable mapping caches and controlled concurrency can make a major difference.

The goal is not to set memory_limit to an unlimited value, but to design the process around predictable resource usage. Shared hosting may require small cron batches, while a VPS can support CLI workers and queue-based processing.

How does scheduled XML synchronization with Cron Job work?

Cron can execute the integration command on a defined schedule. A store may check stock every 15 minutes, prices hourly and run a heavier full-catalog update overnight.

Not every operation needs to run in the same task. Lightweight stock/price checks can run frequently while image and description processing runs less often, improving resource balance on large stores.

A locking mechanism is important. If a new run starts before the previous one has finished, the same products may be updated concurrently. Job locks or queue state can prevent overlap, while logs should record start time, duration, processed-product count and failures.

Can multiple supplier XML feeds be connected to one store?

Yes. Multiple XML sources can feed the same store, but the business rule for identical SKU or barcode values must be defined.

Some projects use supplier priority, others choose the lowest cost or the supplier that currently has stock. More advanced models can combine quantities from multiple suppliers, but order routing must then follow the same logic.

Because each supplier can use different XML field names, a separate mapping profile for each source is usually the cleanest design.

Which e-commerce platforms can receive a custom XML product integration?

Feasibility depends more on technical access than on the brand name. Custom PHP or Laravel projects with source-code and database access can usually be analyzed and given a dedicated integration layer. WooCommerce, OpenCart and PrestaShop can be integrated according to their own product and variation structures.

Closed SaaS platforms do not provide source-code access. In those cases, official API, app, webhook and import capabilities determine what can be done. If the platform does not expose the required operations, external integration may be limited.

For this reason we do not promise that every platform can be connected without inspection. However, you do not need to have purchased your software from us; if sufficient source-code or API access exists, we can evaluate and implement an appropriate method.

Why is the approach different for WooCommerce, OpenCart, PrestaShop and custom PHP?

WooCommerce manages products through WordPress posts, taxonomies, metadata and child variations. OpenCart uses separate product, category, option, language and store relations. PrestaShop has its own combination and feature model. A custom PHP application may have a completely unique schema.

Connecting the same XML to four platforms can therefore mean adapting it to four different data models. Where possible, the platform's own service/model layer is preferred; direct database writes should only be used after data integrity and side effects are understood.

Eka Sunucu provides independent development and technical support services and is not the official support team or an authorized representative of WooCommerce, OpenCart or PrestaShop.

Can the XML be a URL, password-protected feed, gzip file or non-UTF-8 document?

Supplier feeds may be exposed over public HTTPS or protected by Basic Auth, tokens, query parameters or IP restrictions. Authentication can be integrated and credentials should be stored in secure configuration rather than hard-coded into public source.

Large feeds may be delivered as gzip files. Other feeds may use non-UTF-8 encodings, CDATA descriptions or XML namespaces. These are parser-level differences that can be handled when the source is known.

Remote fetches should have timeouts, HTTP status checks, TLS verification and reasonable size limits. If the supplier endpoint is temporarily unavailable, the safer behavior is often to preserve existing store data and mark the synchronization as failed rather than interpreting network failure as zero stock.

Common XML product import problems and how they are approached

Real catalogs frequently contain data-quality problems: missing SKUs, duplicate barcodes, unknown categories, comma-formatted prices, HTML descriptions, inaccessible images and unexpected variation combinations.

A robust integration should not silently swallow errors. It should record which product was skipped and why, continue processing non-critical records where possible and distinguish retryable network errors from permanent data errors.

Suppliers can also change their XML structure without notice. If price suddenly becomes sale_price, the integration should not silently write zero prices; mandatory-field validation and schema-change alerts reduce this risk.

What is the difference between XML import, XML export, CSV, Excel, JSON and API?

XML import brings external data into the store. XML export creates a feed from store data for another system. Both directions may be required in the same project.

If a supplier gives XML but the target accepts only CSV, a conversion layer can transform XML to CSV. XML to JSON, API to XML and store-to-custom-feed transformations are also possible when the target schema is defined.

APIs are often better for real-time transactional communication, while XML feeds remain common for catalog distribution. When an API exists, the sustainable approach should be chosen instead of forcing XML into every use case.

How are security and data integrity handled in XML integrations?

External XML should be treated as untrusted input. Parser behavior, entity handling, maximum size and outbound network access need clear limits, and database writes should use validation and parameterized queries.

Remote image URLs should be restricted to expected protocols and protected against server-side request forgery where appropriate. If administrators can configure feed URLs, authorization and CSRF protection are important.

Before production deployment, the database and critical files should be backed up, staging tests should be used where possible and a rollback path should exist. Change previews can further reduce the risk of a bad mapping modifying thousands of products.

How is an XML integration quote calculated?

A single fixed price is not realistic for every XML project. Importing 500 simple products once is very different from synchronizing 75,000 variable products from several suppliers every few minutes.

Scope is affected by catalog size, XML complexity, variation model, category mapping, image processing, pricing formulas, update frequency, quality of the existing codebase, API limits, number of suppliers and whether a custom administration screen is required.

For a fast initial review, send the XML URL or sample file, store URL and expected rules by WhatsApp. Sensitive server credentials are not required for the first scope review.

Eka Sunucu XML integration workflow

The first step is a technical review of the source feed, target platform and required fields. Scope and limitations are then documented.

Development is performed in a test or staging environment where possible. Mapping, categories, variations, price and stock rules are verified with sample products before a full production import.

At handover, scheduled tasks, update policies and any administration options are documented. If a supplier later changes the XML structure, maintenance may be required, so visible logs and failure reporting are valuable.

• 1. XML and store review
• 2. Field/category/variation mapping plan
• 3. Price and stock business rules
• 4. Pilot import
• 5. Error and duplicate tests
• 6. Full catalog import
• 7. Cron / queue automation
• 8. Production verification and handover