Made-in-China B2B Supplier Scraper — Named Contact

Search made-in-china.com by product keyword and get flat, structured records for every product AND its supplier — including a named contact person, their job title, and the exact mailing address, pulled from the supplier's own public contact page. Most made-in-china scrapers stop at the listing card and hand you a vague "Henan, China" location; this Actor takes one extra hop per unique supplier to surface who you'd actually be emailing and where they really are.

What you get per product

Product fields — title, price, MOQ, product URL, supplier name/location/URL, certifications, product properties (with hs_code pulled out when present), image + image gallery, a company_info summary object, and a scraped_timestamp.

Wedge fields (our undercut) — supplier_contact_name (e.g. "Miss Mia"), supplier_contact_title (e.g. "Manager of International Trade Department"), supplier_address_full (the exact street/city/province/zip, not just a province name), and supplier_contact_url (the page it came from).

Honest framing: phone, email, and WhatsApp are behind a login on made-in-china.com and are intentionally NOT collected — only public, un-gated fields.

How to use it

Set searchQuery to the product you're sourcing (e.g. "led lights"), a maxItems cap (0 = all available pages, capped for safety), and leave fetchContact on true to get the wedge fields. Each unique supplier's contact page is fetched once and cached for the whole run, so you're not paying for redundant hops when many products share a supplier. Turn fetchContact off for a faster, cheaper product-only run. The default Apify Residential proxy is billed to your own run — no external account needed.

Reliability

Every record carries a parse_confidence score and a warnings list so a site-structure drift shows up as a measurable signal rather than a silent empty. A supplier whose contact page 404s, redirects to a login, or is otherwise unavailable degrades those fields to null — the product fields still ship.

What the run tells you

• Every run ends with a status message. If made-in-china.com keeps showing its captcha wall, the Actor retries the search page on up to 5 fresh residential IPs (pausing 1-8 s between tries, at most about a minute in total) and then ends as Failed with the reason; nothing is charged for a failed run.
• If the wall appears after some pages were already delivered, you keep those records and the status message and the OUTPUT record say "Partial result".
• A search page without any products ends as Succeeded with the status message "made-in-china.com returned a page with no products ..." and an emptyReason in OUTPUT.
• The prefilled Store example asks for 3 products so the demo run is short; the API default for maxItems stays 20.

Usage statistics

This Actor creates a small, content-free summary at the end of each run. It is used only to monitor reliability and improve this Actor. A copy is saved as USAGE_STATS in your own Apify key-value store, so you can see the exact record created for your run.

Set disableUsageStats to true in the input to opt out. Nothing is sent then; your USAGE_STATS record only says that statistics were disabled.

Only these fields are recorded:

• schema version, Actor name and build number;
• UTC start and finish hour (not a precise timestamp);
• run duration, number of results and time to the first result, each as a coarse range;
• whether the result was empty, the end status, and an error type from a fixed list;
• memory setting and counts of charged events;
• names of the input fields you set, never their values;
• the selected option for input fields that offer a fixed list of choices (for example a sort order).

We do not collect input text, search terms, URLs, domains, usernames, email addresses, names, proxy credentials, tokens, scraped records, output items, raw error messages, stack traces, or hashes of any of those values. Records are kept for no longer than 13 months, used only as aggregated operational statistics, and never sold or shared.

Additional fields (Phase 2)

This Actor also records your Apify user ID, whether Apify marks the account as paying, the size range of list inputs, the selected country when the input offers a fixed list of countries, and one category from a fixed Actor taxonomy. We use these fields only for aggregate reliability, repeat-use and cross-Actor analysis; reports suppress any cell with fewer than five distinct users.

The same disableUsageStats: true input flag turns these fields off too. The user ID is removed after 13 months; we do not export, sell, share, or attempt to re-identify this data.

Run-outcome signals (v2)

To learn whether a run did what it was asked to do, the record also holds a few more coarse ranges and yes/no flags. None of them contains content:

• the result limit you asked for (a range, when the input has one) and what share of it was delivered;
• results delivered per input item you listed (a range);
• output quality as ranges: how fully the result fields were filled, the share of rows that look like errors, the share of duplicate rows, and how many different fields appeared. These are counted in memory while results are saved; no result content is kept;
• how the run was started (console, API, schedule, webhook, another Actor);
• how it ended: stopped by you, timed out, reached the requested limit, stopped by the charge limit, and how many times the platform moved the run;
• if this Actor reports it: how many items to process worked or failed (ranges) and one failure reason from a fixed list;
• a short code made from the names of the input fields you set, never their values.

Repeat-run fingerprint (v2)

When your Apify user ID is recorded (see above), the record also holds an 8-character one-way code made from your input (proxy settings left out) and this Actor's name. It only lets us see that the same account ran the same input again soon after an unsatisfying run; we never see the input itself. It is stored only in the database, never published, and reports use it in aggregate with the same five-user minimum. It is the one exception to the statement above that no hashes are collected, and disableUsageStats: true turns it off.