Hi Team, I have a written a job which performs a sequence of Gooddata api calls and one of the

put

api calls returning

404 not found

Though when I tried to replicate same issue it works fine. put /api/v1/layout/workspaces/CA_eZCS2OBjvL_mM56Bc7aJ_YUBHRbV0ZWJS/permissions body: {"hierarchyPermissions":[{"assignee":{"id":"CA_eZCS2OBjvL_mM56Bc7aJ_YUBHRbV0ZWJS","type":"userGroup"},"name":"VIEW"},{"assignee":{"id":"CA_eZCS2OBjvL_mM56Bc7aJ_YUBHRbV0ZWJS-admin","type":"userGroup"},"name":"ANALYZE"},{"assignee":{"id":"CA_eZCS2OBjvL_mM56Bc7aJ_YUBHRbV0ZWJS-admin","type":"userGroup"},"name":"EXPORT"}],"permissions":[{"assignee":{"id":"CA_eZCS2OBjvL_mM56Bc7aJ_YUBHRbV0ZWJS","type":"userGroup"},"name":"VIEW"},{"assignee":{"id":"CA_eZCS2OBjvL_mM56Bc7aJ_YUBHRbV0ZWJS-admin","type":"userGroup"},"name":"ANALYZE"},{"assignee":{"id":"CA_eZCS2OBjvL_mM56Bc7aJ_YUBHRbV0ZWJS-admin","type":"userGroup"},"name":"EXPORT"}]} https://wizehive-zengine.cloud.gooddata.com/ Could you please look into it ?

Looking at your screenshots and the error details, here's what's happening: Your job is calling

PUT /api/v1/layout/workspaces/CA_eZCS2OBjvL_mM56Bc7aJ_YUBHRbV0ZWJS/permissions

and receiving a

404 Not Found

with the message: > "The requested endpoint does not exist or you do not have permission to access it." The trace ID from your logs is

69c2ea8a000000004c43f391d4e20608

. Likely Causes Based on similar cases in the community, the most common reasons for this intermittent 404 are: 1. The workspace or user group did not exist yet at the time of the call. Your job runs a sequence of API calls — if the workspace

CA_eZCS2OBjvL_mM56Bc7aJ_YUBHRbV0ZWJS

or the user groups referenced in the body were created in an earlier step of the same job, there may be a timing/race condition where the permissions call fires before the workspace/groups are fully provisioned. [404 Not Found case] [workspace permissions 404] 2. A transient platform issue. Similar intermittent 404/500 errors have been observed and resolved on their own after a short time. [API errors] Recommended Actions • Add a retry with a short delay between the workspace/user group creation steps and the permissions call in your job sequence. • Provide the trace ID (

69c2ea8a000000004c43f391d4e20608

) to GoodData support so they can inspect the logs and confirm whether the workspace or user groups existed at the time of the call. [API errors] • Verify that the user groups

CA_eZCS2OBjvL_mM56Bc7aJ_YUBHRbV0ZWJS

and

CA_eZCS2OBjvL_mM56Bc7aJ_YUBHRbV0ZWJS-admin

exist in your organization before the permissions call is made. Since you cannot reproduce it consistently, this points strongly to a race condition in your job sequence rather than a persistent configuration issue. 👍 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.

Before this api call the workspace had already been created successfully and returned 201 created.

Hi Vivek, I've reviewed the Grafana logs for trace ID

69c2ea8a000000004c43f391d4e20608

and we now have a definitive root cause — it's not a timing issue with the workspace. Root Cause: User groups did not exist yet when the permissions call was made The logs show the following sequence, all within the same second at `2026-03-25 102947`: ❌

GET /api/v1/entities/userGroups/CA_eZCS2OBjvL_mM56Bc7aJ_YUBHRbV0ZWJS

→ 404

exc: "userGroup: CA_eZCS2OBjvL_mM56Bc7aJ_YUBHRbV0ZWJS"

❌

GET /api/v1/entities/userGroups/CA_eZCS2OBjvL_mM56Bc7aJ_YUBHRbV0ZWJS-admin

→ 404

exc: "userGroup: CA_eZCS2OBjvL_mM56Bc7aJ_YUBHRbV0ZWJS-admin"

✅

POST /api/v1/entities/workspaces

→ 201 Created (workspace created here) 1. ❌

PUT /api/v1/layout/workspaces/CA_eZCS2OBjvL_mM56Bc7aJ_YUBHRbV0ZWJS/permissions

→ 404 The GoodData backend validates that all assignees referenced in the permissions payload actually exist before applying them. Since both user groups were not found in the system at that moment, the permissions PUT was rejected. ✅ Fix: Create the user groups before calling the permissions endpoint Add a step earlier in your job to create both user groups via:

POST /api/v1/entities/userGroups

Example body: json

{
  "data": {
    "type": "userGroup",
    "id": "CA_eZCS2OBjvL_mM56Bc7aJ_YUBHRbV0ZWJS",
    "attributes": {
      "name": "CA_eZCS2OBjvL_mM56Bc7aJ_YUBHRbV0ZWJS"
    }
  }
}

Repeat for the

-admin

group. Once both groups exist, the

PUT .../permissions

call will succeed. Why it's intermittent: The user groups likely already exist on most runs (created during a previous job execution). The failure only occurs on the first run for a new workspace, or any time those groups have been deleted. Let us know if you need any further help!

Hi @Joseph Heun, checked the logs again, the user groups had been created and returned 201 created as well.

Hi Vivek, would it be possible to modify your steps a bit and add a verification GET that polls until the entity returns 200 after creating each user group? A poll with a 1–2 second retry interval and ~30 second timeout should be more than sufficient. This guarantees the entities are fully propagated before downstream calls depend on them.

Yeah, but I just want to understand the issue, why the api call returned 404 not found ?

The GoodData docs explicitly call out that user group writes via the declarative layout APIs are eventual — a

201

confirms the write was accepted, but propagation across nodes takes additional time. The recommended fix remains the same: either poll with a GET until the group returns

200

before firing the permissions call, or switch to the

managePermissions

action endpoint which handles this more gracefully. The official docs also recommend

managePermissions

over the declarative

PUT .../permissions

for exactly this type of workflow.

Thanks @Joseph Heun — could you share the relevant best practices docs?

We don't really have a best practices docs, but you can use the following for reference: https://www.gooddata.com/docs/cloud/manage-organization/manage-users/ https://www.gooddata.com/docs/cloud/api-docs/api-reference/user-management#description

@Joseph Heun How the managePermissions action endpoint different from the layout permissions endpoint ? Is it internally handles the retry logic ?

Hello Vivek, Here are some differences between the managePermissions action endpoint different from the layout permissions endpoint: Scope • managePermissions target a single, specific workspace directly while layout permissions target a broader scope, i.e they can apply to the full workspace layout or even the entire organization. Required Permission • managePermissions requires Organization.MANAGE or Workspace.MANAGE (hierarchyPermission) while layout permissions requires Organization.MANAGE only. Method managePermissions uses *POST while l*ayout Permissions uses PUT Propagation Handling • managePermissions handles propagation more gracefully (recommended for automation workflows) while Layout Permissions is subject to eventual consistency, a 201 response (e.g., after creating a user group) does not guarantee immediate availability You can find more information on how these endpoints work in our docs here: Set Workspace Permissions Regarding the other questions, we will review this internally and get back to you as soon as possible.

Hi Vivek, To answer your question about polling — yes, I believe that polling is feasible and is the recommended approach for this type of workflow. After creating each user group (receiving

201

), add a verification step before proceeding to the permissions call:

GET /api/v1/entities/userGroups/{id}

— retry every 1–2 seconds until you receive

200 OK

1. Only then call

PUT /api/v1/layout/workspaces/{id}/permissions

A timeout of 30 seconds is definitely more than sufficient in practice. Regarding

managePermissions

— I need to correct the above statements a bit.. the key difference between the two endpoints is semantics, not propagation behavior: •

PUT /api/v1/layout/workspaces/{id}/permissions

— declarative, replaces the entire permission set at once (useful for IaC/backup-restore scenarios) •

POST /api/v1/actions/workspaces/{id}/managePermissions

— granular, assigns/updates specific permissions per assignee Both endpoints validate that referenced user groups exist at the time of the call. Neither has built-in retry or propagation-wait logic. The polling approach is therefore the correct solution regardless of which endpoint you use. Let us know if you have any further questions!