Vivek Kushwaha
03/23/2026, 9:30 AMkapa.ai
03/23/2026, 9:30 AM500 Internal Server Error from GoodData is a server-side error, which means it cannot be fixed on your end. [API Errors docs]
Here's what you should do: Immediate Steps 1. Capture the traceId: Check the full JSON response body for a traceId field (e.g., {"detail": "Server-side problem. Contact support.", "status": 500, "traceId": "..."). This is the key piece of information GoodData support needs to locate the relevant logs. [API Errors docs]
2. Check the GoodData status page at support.gooddata.com for any active incidents in your region that might explain the errors.
3. Try invalidating the cache for your data source — this has resolved 500 errors in some past cases. [Cache Management]
4. Retry the request — some 500 errors are temporary and resolve on their own. [API Errors docs] Contact Support If the issue persists, open a support ticket at support.gooddata.com and include:
• Your organization URL: wizehive-zengine.cloud.gooddata.com
• The traceId from the error response
• The specific endpoint affected: /api/v1/entities/workspaces/.../analyticalDashboards
• When the issue started and how frequently it occurs
If this is production-impacting, mark the ticket as Severity 1.
> Note: As a community AI assistant, I'm not able to directly investigate your environment or access GoodData's internal logs. The GoodData support team will need to look into this on your behalf using the traceId. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups.
👀 Our Support team monitors all messages and will jump in if needed.Shamil Akhmadyshev
03/23/2026, 10:21 AM76KLwQBl3fARhq8qqDraOkLZ-EBkZP2MIxzs. Can you please double-check it?
After that, I tested this API endpoint in my internal project and received a normal response.
Also, please provide the full JSON body of the error that you are receiving.Vivek Kushwaha
03/23/2026, 11:22 AMShamil Akhmadyshev
03/23/2026, 1:32 PMGET /api/v1/entities/workspaces/{id}/analyticalDashboards and identified the cause on your side.
Your ZenQL application is sending two identical requests simultaneously from two different servers (IPs 3.210.86.150 and 35.169.147.253) to the same endpoint for the same workspace. This concurrent duplicate request pattern causes intermittent failures. When we tested the same requests individually (e.g. from Postman), the API consistently returns the expected 404 response, as you said too.
Additionally, your HTTP client is sending malformed traceparent headers — the trace IDs have the first 16 characters set to zeros (e.g. 0000000000000000d3aae22fbaba3b1f), which does not conform to the W3C Trace Context specification.
To resolve this, please:
1. Remove the duplicate concurrent requests. Your application should send a single request per workspace, not two from different servers at the same time. This is the primary cause of the intermittent 500s.
2. Fix the traceparent header. Ensure your HTTP client generates fully random 32-character hex trace IDs per the W3C Trace Context standard. The current format with leading zeros is invalid and may cause unexpected behavior.
3. Review the access pattern. We noticed your application is querying analyticalDashboards for a large number of non-existent workspace IDs in rapid succession. If possible, please validate workspace existence before querying sub-resources, or cache known workspace IDs to reduce unnecessary calls.
Once these changes are applied, the 500 errors should stop. Let us know if you have any further questions.Vivek Kushwaha
03/23/2026, 6:33 PM