Scraper 'item' method fails with 403 error and code 106

[lucalenardi]

Hello!

I'm encountering an issue where the item scraping method fails intermittently when accessing Vinted.
Most of the time, the server responds with a 403 error and the following body:

{"code":106}

However, on some days (like today), the request instead returns a 404 Not Found error.

Is anyone else experiencing this problem? Everything was working regularly up until a week ago.
If you have found a workaround or know how to fix it, I would really appreciate your advice!

Describe the issue

When attempting to scrape item data from Vinted, the request either:

• Fails with a 403 Forbidden error and body {"code":106}, or
• Returns a 404 Not Found error.

This happens even when using a valid session. It seems that either the API endpoints have changed, or stricter authentication and request validation has been introduced.

Steps to reproduce

1. Initialize the scraper with valid session credentials.
2. Attempt to call the item method on a known valid listing.
3. Observe that after multiple retries, the scraper fails with a 403 (or sometimes 404) error.

Expected behavior

The scraper should successfully retrieve the item data when provided with a valid session and a valid item ID.

Example

scraper = VintedScraper(session_id="valid_session_id")
item = scraper.item("valid_item_id")
print(item)

Tell us about your environment

• OS: Ubuntu
• OS Version: 22.04
• Python version: 3.11

Other information

• Observed errors:
  • Most days: 403 Forbidden with body {"code":106}
  • Some days: 404 Not Found error instead
• Related issue: Vinted may have updated its API, requiring new or stricter headers, authentication tokens, or request formats. IP or session-based blocking may also be involved.
• Suggestion:
  • Review and update request headers (User-Agent, Accept-Language, etc.) to better mimic a real browser.
  • Investigate if additional authentication parameters are now required.
  • Check if URL patterns or anti-bot protections have changed.

Any insight or workaround from other users would be greatly appreciated!

[Giglium]

Hi @lucalenardi,
You can find a lot of info about the 403 status code on #59

For the 404 status code is the first time, maybe they were old links? Have you tried to open the later or in the browser, did you get the same results?

To respond to your suggestions:

1. Request headers seem up to date: https://github.com/Giglium/vinted_scraper/blob/main/src/vinted_scraper/utils/_misc.py#L67-L91 and we update the user agent list every 6 months (maybe we can shorter this period?)
2. I don't think there are any additional authentication parameters otherwise we will receive a 401 status code
3. Probably they introduced a better anti-bot protection, on 403 status code discussion #59 a user suggested that they are using Datadome

[lucalenardi]

Hello @Giglium!
Thanks for getting back to me.

Yes, the 404 is new and unexpected on my side too — I haven't changed anything in the code recently.

Here’s the response I'm seeing:

2025-04-30 18:51:01 - urllib3.connectionpool - DEBUG - https://www.vinted.it:443 "GET /api/v2/items/6233793455 HTTP/1.1" 404 None

Could you please confirm if the API URL is still:
https://{base_url}/api/v2/items/{id}
Or has it changed recently?

If we can attribute this behavior to the same root cause as the 403/106 error (e.g., anti-bot protections), I'm happy to close this issue and move the discussion back to #59.

Thanks again!

[Giglium]

Yes the endpoint is https://{base_url}/api/v2/items/{id} and it's not changed.

Let's see if someone experiences a similar behavior.

[lucalenardi]

Yes the endpoint is https://{base_url}/api/v2/items/{id} and it's not changed.

Let's see if someone experiences a similar behavior.

Thanks for confirming the endpoint hasn’t changed.

Strangely, by simply installing vinted_scraper in a clean environment and running the example code from the project’s README, I’m still getting a 404 response. I tested this on two different servers located in two different continents, with the same result.

At this point, it seems unlikely to be linked to session state or local configuration. Possibly Vinted is now blocking certain automated requests even earlier in the request cycle, returning 404 instead of 403 in some cases.

[lucalenardi]

Also using async version, same result:

KeyboardInterrupt

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/administrator/Sandbox/python/vscraper/test.py", line 65, in test_async_quick_start
    await scraper.item(items[0].id)
  File "/home/administrator/Sandbox/python/vscraper/lib/python3.9/site-packages/vinted_scraper/_async_vinted_scraper.py", line 36, in item
    response = await super().item(item_id, params)
  File "/home/administrator/Sandbox/python/vscraper/lib/python3.9/site-packages/vinted_scraper/_async_vinted_wrapper.py", line 150, in item
    return await self._curl(f"/items/{item_id}", params=params)
  File "/home/administrator/Sandbox/python/vscraper/lib/python3.9/site-packages/vinted_scraper/_async_vinted_wrapper.py", line 188, in _curl
    raise RuntimeError(
RuntimeError: Cannot perform API call to endpoint /items/6251361832, error code: 404

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/unittest/async_case.py", line 102, in _asyncioLoopRunner
    ret = await awaitable
  File "/home/administrator/Sandbox/python/vscraper/test.py", line 76, in test_async_quick_start
    self.fail(
  File "/usr/lib/python3.9/unittest/case.py", line 670, in fail
    raise self.failureException(msg)
AssertionError: Quick raised an exception after 5 attempts: Cannot perform API call to endpoint /items/6251361832, error code: 404

[lucalenardi]

Hello, I confirm that this endopoint https://{base_url}/api/v2/items/{id} always returns a 404.
Can someone confirm it is not something wrong on my side?

Thanks!

[Giglium]

Hi @lucalenardi,
sorry for the delay I was a bit busy. You are right, it seems to have been removed!

I've checked the failed run of the GitHub action: https://github.com/Giglium/vinted_scraper/actions/runs/14771033849/job/41470997817 and we have the same error!

Checking the Vinted Website I haven't seen any replacement.

[lucalenardi]

Hi @lucalenardi, sorry for the delay I was a bit busy. You are right, it seems to have been removed!

I've checked the failed run of the GitHub action: https://github.com/Giglium/vinted_scraper/actions/runs/14771033849/job/41470997817 and we have the same error!

Checking the Vinted Website I haven't seen any replacement.

Thanks for the feedback — at least I'm not completely screwed. 🙂

Now we need to understand whether it has been replaced or permanently removed.

[lucalenardi]

Hi everyone,

I just wanted to share some quick info for anyone updating their code to fetch item details from Vinted, since the previous /api/v2/items/{id} endpoint is no longer working and now always returns a 404.

How to fetch item details now:

• You should now use the /api/v2/items/{id}/details endpoint instead of /api/v2/items/{id}.
• The base URL remains the same, so the new pattern is:
  https://www.vinted.it/api/v2/items/{item_id}/details

What’s changed in the response:

Unfortunately, the response format has also changed significantly:

• Many fields have been removed (e.g. created and updated timestamps, which I used a lot)
• Several fields have been moved into different sub-dictionaries within the JSON response
• Some data is now accessible only through additional sub-endpoints (e.g. /plugins/similar_items)

That means vintedItem.pywill need an heavy lifting...

If anyone finds additional differences or has a field mapping list, please share!

Hope this helps!

[Giglium]

Thanks, @lucalenardi for the info. I've added this to the roadmap for the V3 version #73.

I'm very busy during this period but I will try to work on it as soon as I can.