Bright Data support — Cardmarket load-more pagination questions (Web Unlocker / Scraping Browser / Scraper Studio)

brightdata-support-email.md

To: support@brightdata.com — Cc: David El Kaim

Subject: Stateful "load more" pagination on a Cloudflare site (Cardmarket) — Web Unlocker vs Scraping Browser vs Scraper Studio

Hi team,

I'm working with David El Kaim (in Cc) on evaluating Bright Data for CardNexus. We scrape competitor marketplace price data, starting with Cardmarket (Cloudflare-protected), at ~5–7M requests/month to begin with. We handle all parsing in-house — what we need from you is a reliable Cloudflare bypass that returns the HTML, including the paginated offers.

What already works

Web Unlocker (api.brightdata.com/request) with country=de on a Cardmarket product page:

• Clean HTTP 200, routed via the Cloudflare Munich edge, full page 1 returned (the 50 cheapest offers). No complaints here — the unlock is solid.

The blocker: the "load more" pagination

Cardmarket loads additional offers via a stateful AJAX POST to https://www.cardmarket.com/en/Pokemon/AjaxAction/Product_LoadMoreArticles. That request only succeeds if the CSRF token (__cmtkn) from page 1 is sent together with the matching session cookie (PHPSESSID) from the same exit IP that loaded page 1.

Testing the Web Unlocker /request API, I hit three walls:

1. The page-1 GET response does not expose Set-Cookie, so I never receive the PHPSESSID.
2. The session parameter is accepted, but a cookie set on one call is not present on the next call with the same session value — i.e. no cookie jar is preserved across requests.
3. POSTing the __cmtkn to the AJAX endpoint therefore returns a Cardmarket 502 (the token is "orphaned" — no matching session).

Questions

1. Web Unlocker + manual cookie (David's suggestion). Is there a supported way to (a) have Web Unlocker return the target's Set-Cookie so we can capture the PHPSESSID, and (b) send it back via a custom Cookie header on a follow-up POST, while keeping the same exit IP across the two requests? If yes, which zone settings / request parameters enable this — and does the "Custom Headers & Cookies" pre-approval cover a site session cookie like PHPSESSID (your docs mention login/auth cookies are not allowed)?

2. Scraping Browser. David indicated this is the product that makes sense for interactive pagination. Can you confirm it can (a) drive the "load more" clicks and (b) hold the session across them — and give indicative pricing? Specifically, an estimate of GB consumed per product (page 1 + ~2–3 "load more" clicks) would let us model $/product at our volume.

3. Scraper Studio (per-page-load model). David also mentioned a scraper built via your IDE, billed per page load. Can a Studio scraper perform this "load more" pagination? What is the per-page-load rate, and how is a "page load" counted — is the initial page + each "load more" click counted as separate page loads (so ~3–4 per product), or one per product?

4. SLA & billing on failure.

• What success-rate SLA do you offer for Cardmarket?
• What is billed on failure — are blocked/failed requests charged?
• Does enabling custom headers/cookies switch billing to 100% of requests (success + failure), as your docs suggest?

Context for sizing

For reference, across our catalogue ~60% of products have more than 50 offers (avg ~2.7 "pages" per product), so pagination isn't an edge case — it's the majority of the volume. That's why how the "load more" is counted and priced is the single most important factor in our decision.

Happy to set up a session with a sales engineer in the coming days (as David proposed) to go through the options together.

Thanks a lot,

Tristan Foureur CardNexus