Very long upload times since 5.5.2026

Hello, what changes did you make on August 5, 2026? Since that day, uploading an item has been taking more than a minute. Unfortunately, I haven't been able to look into this until now, hence the late inquiry.

Hello klaus_schneider,

We experienced some slowdowns on our servers around that time. The slowdowns should no longer be an issue at this time.
Are you still experiencing them?

Kind Regards,
--
Thomas
Delcampe Team

Hello, yes, today it took just under 10 hours for 200 items. It started sometime on August 5th, and I noticed it when the date changed to August 6, 2026. Best regards.

Hello, the problem hasn't been resolved yet; after submitting a request, it takes 2–3 minutes to receive the message "Your Request is taken into your Account." One could just about live with anything under a minute, but 3 minutes—that’s simply unacceptable...

Hello, the problem still hasn't been resolved. As it currently appears to us, Delcampe is delaying every request by one minute—or rather, there is a one-minute wait before the acknowledgment or confirmation for the request is received. We pay for the API every month. The current situation is causing significant problems with inventory synchronization. The fact that we aren't receiving any information about the issue is also unacceptable... so, what is the current status? Best regards.

Hello klaus_schneider,

I had misunderstood your problem. I've run several tests on my side, including with your account configuration, and every request completed in less than 100 ms — so the delay doesn't seem to occur while your request is being processed by our servers. To help us find out where the time is actually spent, could you answer a few questions?

1. Which endpoint do you use to list an item: POST /item or the bulk POST /item/bulk?
Do you observe the same delay with both?

2. How do you attach the images?

3. Do you send your requests one at a time, or several in parallel?

A quick test that would tell us a lot: list one single item with one small image URL.
If that call answers instantly, the delay grows with what you send along each item.

If you use curl (or your library exposes timing details), the timing breakdown of one
slow call (time_pretransfer, time_starttransfer, speed_upload) would pinpoint the
bottleneck immediately.

Best regards,
--
Thomas
Delcampe Team

Hello, an upload is currently in progress. The problem only started occurring on August 5th; up until then, there were no issues... so what was changed on August 5th? It is certainly possible that something is no longer compatible due to the change made on that date. However, if we don't receive information about upcoming changes, we cannot react. This is a recurring problem that disrupts operations, even though improvements have been promised multiple times. I have a deadline right now, so I can only carry out a more in-depth investigation overnight or over the weekend... Best regards.

We probably found the cause of the delays. Our servers answer each of your calls in under half a second; the remaining time is spent waiting on an idle connection. Here is a network capture of one of your POST /item calls:

T+0.00 s request received in full (~12 KB)
T+0.35 s our response is sent and acknowledged by your system
... no traffic in either direction ...
T+65.3 s our server closes the idle connection (65 s keep-alive timeout)
T+65.4 s your tool opens a new connection and sends the next request

Your HTTP client considers a response finished only when the connection closes, instead of using its Content-Length header. With keep-alive, that close comes 65 seconds after the response. At two calls per item (the GET /item/reference/.../open check, then POST /item), that is ~130 s per item. Roughly the delays you reported.

How to fix it, either option:

1. Send a "Connection: close" header with every request. The connection then closes right after the response and your current logic returns immediately.
2. Better long-term: use a standard HTTP library (libcurl or the equivalent in your language), which detects the end of each response via its framing and keeps keep-alive at full speed.

Two side notes from the same capture:

- Every POST /seller is followed by a few stray bytes, which our server rejects as an invalid request (400) and closes the connection. Harmless and incidentally why those calls are not slow. Likely a Content-Length mismatch on sending.
- Your item URLs contain a double slash (/item//reference/...). It works, but should be normalized.

With 'Connection: close' in place, the time per item should drop from ~2 minutes to under a second.

Please let us know how it goes after the change.

Kind Regards,
--
Thomas
Delcampe Team

Hello, first of all, thank you very much for the information. We can now investigate this in more detail. Best regards.