/item/{id} timestamps are off

Example: Lien (https)

Item n°2627980937
Start of the sale: Monday, 14 September 2026 at 08:43
Sale ends: Monday, 12 October 2026 at 08:43

But the API says this:
```
[creation_date] => 2026-09-14 06:09:23
[date_start] => 2026-09-14 06:09:22
[date_end] => 2026-10-12 06:10:22
```

On that note: would it be possible to add the timestamps date_start and date_end to the `Seller_Item_Add` notification payload, please?

When using the `item/fixedprice/opened` endpoint I receive different values for date_end.

Hi fnwbr,

Thanks for the detailed report, it helped us pinpoint the problem quickly. Two separate things add up here.

1. Time zone (expected behavior)
Dates returned by the API are in UTC, without a time zone offset, whereas the website displays them in your local time zone. In September, Germany is on UTC+2, hence the 2 hour difference: 06:43 UTC = 08:43 in Germany. This also applies to prefered_end_hour.

2. Minutes (bug on our side)
In creation_date, date_start and date_end, the minutes are currently replaced by the month number. So in your example, 06:09:22 is actually 06:43:22 (09 = September) and 06:10:22 is actually 06:43:22 (10 = October). That's also why date_end appeared to be one minute later than date_start.

For item 2627980937, the correct values are:
creation_date => 2026-09-14 06:43:23
date_start => 2026-09-14 06:43:22
date_end => 2026-10-12 06:43:22
All in UTC, 08:43 in Germany, which matches the item page.

About item/fixedprice/opened it's the same bug. On the list endpoints, date_end is already formatted correctly, so the value you get there is the right one. It's /item/{id} that returns the wrong one.

We're going to fix this and will post here once it's live. After that, /item/{id} and the list endpoints will return the same values. In the meantime, you can rely on date_end from the list endpoints.
For creation_date and date_start, only the minutes are wrong (date, hour and seconds are correct).

Regarding date_start and date_end in the Seller_Item_Add notification, thanks for the suggestion, we've noted it for future development and will get back to you on that.

Best regards,
Alex

Dear Alex, thank you very much for the investigation report. Looking forward to see the fixes once they are live! Have a nice rest of your Wednesday.

Hi fnwbr,

I am glad to announce that the fix is now in production.
Do not hesitate to contact us if you encounter any other problems with the API.

Best regards,
Alex