Neu Shop API webhook returning 403 during external script execution testing

[deltaexector]

Hi everyone, I have been running some automated workflow tests on our staging JTL-Shop 5 instance to check how external order state webhooks react under rapid status changes. While standard backend syncing runs without issues, our external staging client frequently drops connections and returns generic 403 forbidden responses during batch status updates.



We tried inspecting the request payloads from the sandbox environment, and it seems server-side security rules flag the request headers whenever our custom deltaexector script pushes rapid multi-threaded queries to the REST endpoint. The session cookies appear to invalidate mid-process, which leads to interrupted updates and temporary IP blocks on the staging server.



Has anyone experienced similar ModSecurity or Nginx rate-limiting conflicts when running automated testing scripts against JTL endpoints, and what would be the recommended way to whitelist these calls without lowering shop security?

 

[Morimus]

A 403 response alone does not show whether ModSecurity, Nginx, JTL-Shop or your custom integration rejected the request.
Could you clarify which endpoint your script calls and whether it belongs to JTL-Shop or a plugin?

Your description mentions both webhooks and REST requests, so the direction of the failing call is not quite clear.

For one failed request, the HTTP method and path, a redacted response including headers and body, the timestamp, and the matching web server or WAF log entry would help.
Please leave out tokens, cookies and customer data.

I would also repeat the same request with one worker before testing multiple concurrent workers.
If only the parallel test fails, check how the script handles sessions and how quickly it sends requests.
If a WAF rule is confirmed as a false positive, adjust that specific rule for the affected request rather than broadly allowlisting the client IP.