Hi Team, My api calls are frequently receiving 500...
# gooddata-cloud
v
Hi Team, My api calls are frequently receiving 500 internal server error from Gooddata. <- (gooddata) get /api/v1/entities/workspaces/76KLwQBl3fARhq8qqDraOkLZ-EBkZP2MIxzs/analyticalDashboards -> (gooddata) 500 Internal Server Error Env: https://wizehive-zengine.cloud.gooddata.com/ could you please look into it ? Thanks
k
Hi, A
500 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.
s
Hi Vivek, I have impersonated our admin user in your project and can't see any workspace with such id
76KLwQBl3fARhq8qqDraOkLZ-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.
v
Hi @Shamil Akhmadyshev, yes, the workspace doesn’t exist. However, the API should have returned a 404 Not Found error. Do you know why it was returning a 500 Internal Server Error instead? I tried hitting the same endpoint in Postman just now, and it returned a 404 Not Found.
s
Hi Vivek, We've investigated the 500 errors you're seeing on
GET /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.
v
Thanks @Shamil Akhmadyshev