Hi team, We have a

<gd-dashboard>

web component integration. Some time ago, we started seeing the following error in the browser console originating from the imported JavaScript:

GET https://[client name].<http://cloud.gooddata.com/api/v1/entities/exportTemplates?page=0&size=1000|cloud.gooddata.com/api/v1/entities/exportTemplates?page=0&size=1000> 404 (Not Found)

d55a027b-4612-4a41-a…d7e7c5e1cac5:131355 Tiger backend threw an error:{detail: 'The requested endpoint does not exist or you do not have permission to access it.', status: 404, traceId: 'a3325b416496501d7920ea52efbe2d9e'}

To investigate the issue, I tried calling the endpoint directly with Postman (/api/v1/entities/exportTemplates?page=0&size=1000): • Admin user: request succeeds. • User experiencing the browser error: receives the same 404 response.

{

"detail": "The requested endpoint does not exist or you do not have permission to access it.",

"status": 404,

"title": "Not Found",

"traceId": "e18430e630285ce7873d4e7e3b23b174"

}

The user has VIEW access to the workspace and Export (PDF,XSLX,CSV) permissions. Could you please advise what might be causing this?

The knowledge sources do not contain enough specific information to give a definitive answer about why a user with VIEW and Export permissions receives a 404 on

GET /api/v1/entities/exportTemplates

, but based on the patterns seen in similar community cases, here is what is most likely happening and what to check: Likely Cause: Insufficient Permissions for the Export Templates Endpoint The fact that an admin succeeds but a regular user fails strongly points to a permissions gap rather than a platform issue. The

exportTemplates

endpoint may require a higher permission level than VIEW + Export (PDF/XLSX/CSV) on the workspace. From similar cases in the community, the

GET /api/v1/entities/exportTemplates

endpoint may require at minimum

ANALYZE

workspace-level permission, not just

VIEW

. [API errors] Recommended Steps 1. Check workspace permissions — Verify whether the affected user has

ANALYZE

(not just

VIEW

) permission on the workspace. In several similar 404 cases, users appeared to have access but were missing a specific permission level required for the failing endpoint. [workspace permissions] 2. Check organization-level permissions — Export template entities may be organization-scoped rather than workspace-scoped. Confirm whether the user has the necessary organization-level role to list export templates. 3. Share the

traceId

with GoodData Support — Your trace ID

e18430e630285ce7873d4e7e3b23b174

is the key piece. GoodData Support can look up the exact cause in backend logs. End users cannot decode trace IDs themselves — only GoodData's support staff can. [traceId lookup] 4. Capture a HAR file — As recommended in similar embedded dashboard 404 cases, capturing a HAR file from the browser while reproducing the error is typically the most useful artifact for GoodData Support to diagnose the issue. [embedded 404 case] 5. Open a support ticket at support.gooddata.com with: ◦ Your organization URL ◦ The affected user's email ◦ Both trace IDs (

a3325b416496501d7920ea52efbe2d9e

and

e18430e630285ce7873d4e7e3b23b174

) ◦ The HAR file The admin-vs-user discrepancy is the clearest signal here — this is almost certainly a permissions issue specific to the

exportTemplates

resource for non-admin users. 👍 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.

Hi Victor, as you mentioned, with Admin is no issue. As it is stated in our documentation gooddata.ai/docs/…/export-templates "As an administrator, you can use the API to upload your own export template.." Please, review and double check the permissions of the user is making the API call.

Hi @Mauricio Cabezas, thanks! The issue is that we don't have any export templates configured. As far as I understand, the request is being made internally by the imported

tigerBackend.js

. Our application doesn't call that endpoint directly. Could you please clarify why the library is attempting to access this endpoint?

Hi Victor, You're right that your application isn't calling that endpoint directly. The <gd-dashboard> web component (via the imported tigerBackend.js) automatically checks for export templates every time a dashboard loads, regardless of whether any templates are configured. For a non-admin user, that organization-level call will consistently return a 404, which is what's showing up in your browser console. This is expected behavior on our side and does not affect the dashboard, your export functionality, or anything else. Your workspace-level export options continue to work normally. In short: nothing to fix on your end.

@Shamil Akhmadyshev Thank you! Can I ask you something else? 🙂 We started getting this error in the browser console:

Refused to get unsafe header "x-gdc-trace-id"

Should we whitelist this header on our end?

That warning happens because our SDK tries to read the

x-gdc-trace-id

response header from the API call (it uses this to attach the trace ID to error details for diagnostics). Browsers only allow JavaScript to read specific response headers on cross-origin requests — whichever ones the server explicitly exposes via the

Access-Control-Expose-Headers

response header. That's controlled entirely on our backend, not by anything configurable in your app, so there's no client-side setting or header whitelist that would change this. This is a console warning, not a blocking error. The SDK simply falls back to not having that trace ID available client-side; it doesn't affect the dashboard or any functionality. You're likely seeing it alongside the exportTemplates 404 we discussed, since it's the same kind of diagnostic header read happening on an error response.