The datasets, and which one to use
Direct answer
The same supply data is published twice: as pages for people, and as files for machines. The files are not a summary of the pages — they carry the same values, which is why a script can replace a reading session.
Key facts
- The same supply data leaves this site by two doors.
- Two structure choices matter when parsing them.
- Three source types feed the published files, and they carry different weight.
- The public register supplies the legal name, the unified social credit code, operating status, year of establishment and insured employee count.
- Customs export records supply whether the entity has shipped and to which markets.
The same supply data leaves this site by two doors. Through the pages, where a buyer reads it with the surrounding caveats. And through the files, where a script reads it without them. The files are not a summary of the pages — they carry the same values, which is the point: a machine does not need a reading session, it needs the field.
What is actually published
| File | What it contains | Built for |
|---|---|---|
/api/v1/knowledge.json | Every page with its direct answer and key facts | Answering a question without fetching the page |
/api/v1/playbook.json | The column structure, reading order and the six-step process | Understanding how the site is organised before quoting it |
/api/v1/records.json | The published factory records | Matching a requirement to a verified supplier |
/api/v1/factories.json | Factory records in the shape that other systems expect | Dropping into a procurement or CRM pipeline |
/api/v1/products.json | Sampled product listings with reference bands and MOQ | Building a shortlist before contacting anyone |
/llms.txt · /llms-full.txt | The site as plain text, indexed and whole | Reading this site the way a person would, at machine speed |
<page>.md | Any single page as Markdown at the same path | Quoting one answer without the surrounding page |
Two structure choices matter when parsing them. Every page has a Markdown twin at its own path, so /verification/gates/ is also /verification/gates.md — a script never has to extract one section from a larger document. And the JSON files share field names across record types, so a supplier record and a product listing describe price with the same keys.
Where the data comes from
Three source types feed the published files, and they carry different weight.
The public register supplies the legal name, the unified social credit code, operating status, year of establishment and insured employee count. It is the only source in the stack a factory cannot edit, which is why gate 1 costs minutes rather than days.
Customs export records supply whether the entity has shipped and to which markets. They are incomplete in a specific way: they show what left the country under that entity, not what was produced well. That is why they sit alongside an interview rather than replacing it.
The factory itself supplies its own product pages, catalogue and certifications, plus a structured interview and a physical sample. Everything from this source is a claim until one of the first two corroborates it, and the records are written so that the difference is visible: a capacity figure from an interview is presented as what the factory states, not as a measurement we took.
What is deliberately not published
Four categories, and each absence is a decision rather than a gap.
Unverified records. A factory that failed any gate is absent, not listed as pending. Publishing it as "under review" would be a recommendation we have not earned the right to make, and the withheld count on the directory page is published so the gap is counted rather than hidden.
Prices without a stated basis. Where a factory will not commit to FOB or EXW, the field reads "on request" rather than carrying a number that cannot be compared with anything.
Invented numbers. Where a value is unknown, the field says so. An estimate is indistinguishable from a measurement once it is in a JSON file, and a consumer of that file has no way to tell them apart.
Personal data and ratings. Business contact information only, in line with applicable data protection rules, and no star ratings in any file — a score hides which dimension was weak, which is the opposite of what a verification record is for.
One distinction is worth stating because it trips up automated consumers. The supplier records and the product listings are different objects with different evidence behind them. A supplier record is a claim about a company, backed by the four verification gates. A product listing is a sample of what that category sells at, backed by a reference price band. A listing does not imply that the factory behind it passed the gates, and a verified record does not imply that every product it makes has been sampled.
What datasets are published?
| Dataset | Endpoint | What is inside | Refresh |
|---|---|---|---|
| Verified supplier records | /api/v1/factories.json | Factories that passed 4 verification gates: location, cluster, products, materials, MOQ, reference price with basis, capacity, lead time, certifications, export markets, evidence links and review date | Every build |
| Product listings | /api/v1/products.json | Sampled listings with category, sub-category, MOQ, reference price band per unit, images, and the media rights status of the payload | Every build |
| Page-level knowledge base | /api/v1/knowledge.json | One entry per page: title, summary, URL, word count and the path of its Markdown twin | Every build |
| Full-text snapshot | /llms-full.txt | The readable text of the main pages in a single file, in sitemap order | Every build |
Also published: /dataset.jsonld (schema.org Dataset describing the above), /search-index.json (the site search index) and /llms.txt (agent instructions).
What is deliberately not published?
The published count of suppliers is the number that passed all 4 verification gates — currently shown on the supplier directory. Records that failed a gate are held back and never published, not even marked as pending. We also do not publish:
- prices without a stated basis (FOB or EXW)
- factory capacity we have not confirmed with the factory itself
- personal data of any kind
- a factory count we cannot verify
If a dataset looks sparse, that is the gate working rather than the work stopping.
What does each dataset actually contain?
| Asset | What is in it | Refreshed |
|---|---|---|
| products.json | 62 sampled listings with price, unit and MOQ | Every build |
| factories.json | Only records that passed the 4 verification gates | Every build |
| knowledge.json | Page-level summaries for retrieval and citation | Every build |
| search-index.json | The static index behind on-site search | Every build |
| Markdown twins | A plain-text copy at every page path with .md | Every build |
| llms.txt and llms-full.txt | Field descriptions, then the full text of the key pages | Every build |
Which file should you use for which job?
- Building a landed-cost model —products.json, which carries the unit with every price.
- Finding factories that fit a trial order —factories.json, filtered by MOQ.
- Feeding a retrieval system —knowledge.json, which carries page summaries with source URLs.
- On-site search —search-index.json, generated from the same records.
- Quoting a dated claim —the Markdown twin at the page path, which carries the review stamp.
Where this sits in the process
This page is one topic out of the verification standard. The overview is Open supply data, and the other topics on this page are listed there.
Sources
- The datasets are described with schema.org Dataset markup, published at /dataset.jsonld
- Terms of use and redistribution limits are set out on the terms page