#Struggling with Wolt login/cookies on OpenClaw (VPS/Playwright)

1 messages · Page 1 of 1 (latest)

night rain
#

Hey everyone,

I’m currently building a custom sales dashboard for my dad’s restaurant. I’m trying to automate the daily sales export from the Wolt portal (and two other delivery apps) into my database.

My current setup is OpenClaw running on a VPS using Playwright (headless).

The issues is that Wolt uses an email verification link for the initial login. I’ve tried logging in manually once and saving the storage state(cookies), but for some reason, the session doesn't persist or it gets challenged again immediately when running on the VPS.

Has anyone successfully bypassed the Wolt Link or gotten cookies to stick long-term on a headless server?

I don't have access to their official APIs, and I don't have a spare local PC to act as a browser relay, so it has to stay on the VPS. Any advice on how to handle the email auth or a better way to scrape this so i dont need to do this manually?

Thanks in advance!

visual baneBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

still lotusBOT
#

I can’t help with “bypassing” Wolt’s auth/challenges (that’s basically evading their security / ToS), but you can usually make this work in a legit way if you control the account + mailbox.

A few practical things that commonly explain “cookies don’t stick” on VPS Playwright:

1) storageState often isn’t enough (magic-link “device” tokens can live outside it)

Playwright’s storageState covers cookies + localStorage, but some sites bind sessions via other browser profile data (IndexedDB, service worker caches, etc.). In those cases, restoring storageState looks “new device” → immediate re-challenge.

Fix: use a persistent browser profile (userDataDir) so the full Chromium profile is reused.

  • Prefer chromium.launchPersistentContext(userDataDir, …) over “launch + newContext({ storageState })”.
  • Keep that userDataDir stable across runs (same path on disk, don’t recreate container each day).

2) VPS/headless is a higher-risk signal (and some portals re-challenge constantly)

Even if you persist the profile, some vendors will re-verify when:

  • IP reputation is “datacenter/VPS”
  • headless/automation is detected
  • geo/timezone/locale changes between runs
#
  • chromium version changes frequently

You can reduce accidental churn without doing stealthy evasion:

  • Pin the Playwright browser version (don’t auto-update daily).
  • Keep locale/timezone consistent (locale, timezoneId) and run in the same region.
  • Don’t rotate user agents; keep the setup stable.

3) If Wolt insists on email-link every time: automate the email link workflow, not the cookie

If the portal is designed to re-verify regularly, the reliable approach is:

  1. trigger “send me a login link”
  2. poll your mailbox via IMAP/Gmail API (your own mailbox, with permission)
  3. extract the magic link URL
  4. open it in the same persistent context you use for scraping
  5. proceed to export

That’s not a bypass—it’s just automating the same step you’d do manually.