Hi Brian Ntezimana I took a quick look at this because the error is interesting. My read is that Dust is rejecting the request at the data source write-permission check, before it gets to the document itself, so I don’t think PostgreSQL or the document payload is the issue. A few quick tests might help narrow it down:
Try creating a document manually in the same Folder data source from the Dust UI
Try the API call once with a brand-new document ID
Create a new Admin API key and try the same request against the same Space and Data Source
1) If the manual creation works but the API still returns the same 403, that would point more strongly to the API key’s effective write permission.
2) If a new API key works, then the issue is likely specific to the existing key or how its permissions are being resolved.
3) If the new key also fails, then I’d suspect the permission relationship between the Space and that specific Data Source.
I would not create a new Space yet, since that introduces another variable. If needed, a better next test would be creating a new Folder data source inside the same Space and trying the same API call there. Since this started around August 28 and was working before, I’d also send the workspace ID, Space ID, Data Source ID, and 1 recent failed request timestamp to support@dust.tt so they can check the effective permissions on the backend.
Hi Hugues Bocquet Great question! This seems like expected behavior. If an agent uses data from a restricted Pod, Dust restricts the agent to members of that Pod so the agent cannot become a way to access private Pod data. If the goal is for everyone to use the agent, but for the agent to search only a specific set of information, I would not necessarily use a restricted Pod for that. You can:
Keep the approved content in Company Data
Configure the agent’s Knowledge/Search capability to use only the specific folders or sources you want
Keep the agent published and available to everyone
Selecting specific Company Data sources scopes that search capability to those sources. I would just make sure the agent does not have another broader search capability, skill, or Space that gives it access to additional data. If the Pod itself is safe for everyone to access, making the Pod open should also remove the agent restriction. You can do this by following these steps - Pods > {pod_name} > Gear icon > Check Open to Everyone
Hi Mike, I tested a possible workaround using the Dust Chrome Extension. Since the extension can interact with Google Drive through the browser UI, I was able to use it for actions like moving or renaming files. Dust Chrome Extension: chromewebstore.google.com/detail/dust/fnkfcndbgingjcbdhaofkcnhcjpljhdn?hl=en It may be worth trying while those actions aren’t available directly through the native Drive integration. I attached an example of the workflow I tested. I also think your request is a good product-feedback candidate because native move/rename actions would make this much cleaner.
