Job xml-supplier-feed-parse-errors-import · revised 11 October 2026
Read every item in a supplier XML feed, and reject a broken file cleanly
A named supplier XML sample imports every well-formed item, with namespaces, CDATA and escapes read correctly; a broken copy is rejected with its line and column and changes nothing.
You might be seeing
- The whole feed fails to import and the message names a token or position but nobody knows what to ask the supplier
- Some products import without prices or with markup text in their names, because prefixed tags or CDATA sections are not read
No passwords, keys, card details or admin invites needed to start.
What usually happened
The importer reads supplier XML with string matching or an unconfigured parser. Namespaced tags, CDATA sections and escaped characters are skipped or stored with markup in them, and one unescaped ampersand or invalid character elsewhere in the file stops everything without a usable message, or leaves a half-applied update.
Who it’s for: Operations manager or developer at a distributor whose supplier XML feed imports zero items, some items, or stops with an unhelpful message.
Usually starts when: The import fails with a parse message after the supplier's latest file, or items with prefixed tags such as g:price are skipped, or product names contain stray markup.
The result: A named XML sample imports every well-formed item with namespaced fields, CDATA text and escaped characters stored as the agreed values. A deliberately broken copy is rejected as a whole with the line and column of its first error, and the previously stored products are unchanged.
Check whether this job fits
Answer these without sending files, code or logins. Nothing is submitted unless you choose to contact us.
Checks you can run yourself
Read the first error exactly
Copy the parse message, including its line and column, from your import log. Open the file at that line in a plain text editor.
Look for: An unescaped ampersand, a control character, a tag whose closing name differs in letter case, or text after the final closing tag are the usual causes of a not-well-formed file.
What you get
- A change to the importer with its regression test
- A table of the synthetic items, the expected field values and the stored values
- The rejection message for the broken copy, written so you can send it to the supplier
- Steps to revert the change
Included
- One existing importer path for one named supplier XML layout
- Reproduce the fault on a synthetic sample built from your redacted file, with up to six item-level cases (namespace prefix, CDATA, escaped ampersand, missing optional element, repeated element, empty element)
- Read the file with a real XML parser configured for the agreed layout, including its namespaces, and map the agreed fields
- Reject a file that is not well-formed with the first error's line and column, before any product is changed
- Refuse documents that declare entities or external resources unless your layout needs them, and add a regression test
Not included
- Correcting the supplier's XML so that it becomes well-formed; we report exactly what the supplier must fix
- Designing a schema or XSD for the supplier
- Converting XML to another feed format for a different platform
- Tuning very large files beyond the agreed sample
- Outbound XML feeds you send to a shopping platform, which are a different job
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
The synthetic well-formed sample imports every item, with the namespaced price, the CDATA description and the escaped ampersand each stored as the agreed value.
Evidence: Expected and stored values side by side for each synthetic item.
A copy of the sample with one unescaped ampersand is rejected as a whole with the line and column of the first error, and the stored products are identical before and after the attempt.
Evidence: The rejection message and a before and after comparison of the test store.
A synthetic file declaring an entity or an external resource is refused, or the entity is left unexpanded, as agreed, and nothing is fetched.
Evidence: Test output and the parser settings in the change.
The importer's existing tests still pass with the change applied.
Evidence: Full test run output attached to the change.
Sign-off. You inspect the stored values, the rejection message and the test results, and sign off in writing. Payment follows sign-off; applying the change live stays with your maintainer.
If it fails. If the agreed sample does not import as specified, you do not pay for this fixed scope. We hand over what we found and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- The importer is code you can share through an agreed route and it runs locally on synthetic data
- The XML comes from a named supplier feed, not arbitrary files uploaded by the public
- You can supply a redacted sample that reproduces the fault
We stop and tell you if
- The supplier file relies on a document type definition or external entities that the importer must resolve: we explain the risk and quote separately
- The only reproduction needs production data or credentials
- The feed is a stream or archive format that cannot be read from a file
What could go wrong
Before you merge, closing the change leaves the importer as it was. After merge, your maintainer can revert the named commit. Products stored by earlier imports are not changed by this job.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A permissive parser expands entities or fetches external resources from a file you do not control. | Acceptance includes a synthetic file with an entity declaration that must be refused or left unexpanded, and parser settings are reviewed independently. |
| A repaired-looking file is accepted when it is actually broken, storing partial products. | A file that is not well-formed is rejected as a whole before any product changes. |
| Supplier files with real prices are sent as samples. | The first enquiry asks for redacted or invented items only. |
An independent reviewer checks the stored values against the expected table, that the broken copy changes nothing, and that the parser settings do not fetch external resources. Your maintainer reviews and applies the change.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree the importer path, the layout, the item cases and the expected values in writing
- Reproduce the failure on a synthetic sample and record the parser's first error with line and column
- Replace string matching with a configured XML parser mapping the agreed fields and namespaces
- Check before any write that the file is well-formed and that entity and external resource handling follows the agreed rule
- Run the good sample, the broken copy and the existing tests, and compare stored values with expected values
- Independent review, then hand over the change, evidence and revert steps for your maintainer to review and apply
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access and any needed permissions are in place. Hosting, supplier and platform charges are excluded unless the written quote includes them. An enquiry creates no charge or booking.
Need to keep it working?
Discuss a standing check that tests every new supplier XML file against the agreed layout.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Ask the supplier to validate their file with any XML parser before sending it. A file that is not well-formed is the supplier's to correct; the XML specification treats it as a fatal error. www.w3.org
- If your platform has a built-in XML import, check whether it lets you choose the item element and map namespaced fields before writing code.
Questions
Can you make a broken supplier file import anyway?
Not as part of this job. A file that is not well-formed cannot be read reliably, and repairing it by guesswork can store wrong products. We make the message precise so the supplier can fix it.
Does this change the products I already have?
No. This job changes how future files are read. Earlier imports are not touched.
Is this the same as the Merchant Center feed job?
No. This job reads a supplier's file coming in. The Merchant Center jobs concern the file you send to Google.
Send an enquiry
Send us
- A redacted XML sample with three to six items, including the item that goes wrong, as text
- The exact parse message, with any private path removed
- The importer's name and language. No real price lists, customer data, credentials or code in the first enquiry
Later, once you agree
- The importer code through an agreed company-controlled route, with local run instructions
- Redacted sample files and expected field values, agreed in writing
- A named person who can accept the change
You keep the importer, your database and the supplier relationship. We work on a copy of the importer with synthetic or redacted files and return a change your maintainer reviews and applies. We do not hold supplier credentials or touch production data.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “xml-supplier-feed-parse-errors-import” as the subject.