Hey Permit team, We have started to notice few iss...
# permit-saas
a
Hey Permit team, We have started to notice few issues with the Permit APIs. Esp the API which remove and add permissions. We are calling the APIs in this order REMOVE Permissions API - DELETE
/schema/wrkr/${this.environment}/roles/${role}/permissions
ADD permissions API- POST
/schema/wrkr/${this.environment}/roles/${role}/permissions
(edited)
a
Hi @Ash, I'm an AI assistant for Permit.io. I'll analyze available sources and get back to you shortly.
a
we are populating a big chunk of permissions (approx 75 -100 permissions per role in each API call) in that ☝️ order with very little delay (sleep) between the remove and add APIs The API removes the permissions successfully but fails to add the permissions back. We have started to notice this since yesterday. Has something changed on your end?
a
I can help you troubleshoot the permission API issues you're experiencing. Based on the documentation, the correct endpoint structure for removing permissions from a resource role is: ​*DELETE*​
/v2/schema/{proj_id}/{env_id}/resources/{resource_id}/roles/{role_id}/permissions
(1) The endpoint requires the following path parameters : • `resource_id`: Either the unique id of the resource, or the URL-friendly key of the resource (i.e: the "slug") • `role_id`: Either the unique id of the role, or the URL-friendly key of the role (i.e: the "slug") • `proj_id`: Either the unique id of the project, or the URL-friendly key of the project (i.e: the "slug") • `env_id`: Either the unique id of the environment, or the URL-friendly key of the environment (i.e: the "slug") The body should contain the permissions to remove in this format :
Copy code
{
  "permissions": [
    "document:share"
  ]
}
Note that if some of the permissions specified are already unassigned, the API will skip them . To help our engineers investigate your specific issue, could you please provide: 1. Which Workspace / Project / Env you are using 2. What calls you are performing (as SDK code or CURL) 3. Which PDP version you are running 4. Relevant logs from your PDP This information will help us identify what might be going wrong with your permission API calls.
To learn more, see the sources I considered: [[1] DELETE /v2/schema/{proj_id}/{env_id}/resources/{resource_id}/roles/{role_id}/permissions](https://api.permit.io/v2/redoc#tag/Resource-Roles/operation/remove_permissions_from_resource_role)
n
Hi @Ash thanks for reaching out. Let me know if you tried with the end point that AI agent suggested.
a
I think the AI is mistaken. we are using the API from your docs. The resource is not in the slug
Copy code
<https://api.permit.io/v2/redoc#tag/Roles/operation/remove_permissions_from_role>
this is the API
Copy code
<https://api.permit.io/v2/schema/{proj_id}/{env_id}/roles/{role_id}/permissions>
resource key is in the body
@Natalia Edelson
n
Oh I see. Let me check with the team and get back to you. @Ask Inkeep
a
Thanks for tagging me @Natalia Edelson. I'll look through relevant sources and get back to you shortly.
You're absolutely right, and I apologize for the confusion in my previous response. You're using the correct endpoint for removing permissions from roles (not resource roles) . The endpoint you're using:
Copy code
DELETE /v2/schema/{proj_id}/{env_id}/roles/{role_id}/permissions
is the correct one for removing permissions from roles, where the resource key is specified in the request body. Given that you're experiencing issues with the ADD permissions API failing after successfully removing permissions, especially when handling 75-100 permissions per role with minimal delay between calls, this could be related to: 1. ​*Rate limiting or throttling*​ on the API side 2. ​*Race conditions*​ when making rapid sequential calls 3. ​*Potential timing issues*​ with permission propagation To help our engineers investigate this issue properly, could you please provide: 1. Which Workspace / Project / Env you are using 2. What calls you are performing (as SDK code or CURL) - including the exact body payloads 3. Which PDP version you are running 4. Relevant logs from your PDP Additionally, could you share: • The exact error message or response you're receiving from the ADD permissions API • Whether this happens consistently or intermittently • The approximate delay you're using between the REMOVE and ADD calls This information will help the team identify what changed and resolve the iss
Feel free to tag me with additional questions. I also appreciate feedback, it helps me improve. 👍 button 👎 button
a
@Natalia Edelson @Ask Inkeep 1. Project:
wrkr
, Env:
stage/test/all
2. Simple
await fetch()
nodejs call 3. No error message, when checked for permissions on SaaS, no permissions "ticked" 4. Delay is 200 milliseconds between remove and add
a
Thanks for tagging me @Ash. I'll look through relevant sources and get back to you shortly.
The issue you're experiencing with permissions not appearing after the ADD API call, despite no error messages, is likely related to ​*data synchronization timing*​ between the Permit API and your PDP. When you make rapid API calls (200ms apart) that modify permissions, there can be a delay before those changes propagate to the PDP. This is a known consideration in distributed authorization systems (1) . *Recommended Solution: Use "Send Consistent Updates" (Read-Your-Own-Writes) * Permit.io offers a feature called ​*Send Consistent Updates*​ that ensures data changes are immediately available for permission checks by routing requests through the PDP and waiting for synchronization before responding . To enable this in your Node.js code:
Copy code
const permit = new Permit({
  token: "<your-api-key>",
  pdp: "<http://localhost:7766>",
  proxyFactsViaPdp: true
}) ;
With
proxyFactsViaPdp
enabled, API calls wait until data is fully synced to the PDP before returning, ensuring permission checks work immediately after . ​*Important Notes:*​ • This feature requires ​*PDP version 0.5.1 or above*​ • It increases API latency but provides faster sync times compared to direct Permit API calls • It works best when PDPs are deployed as Centralized PDPs or Sidecars to your application ​*Alternative Approach:*​ If you cannot use the above feature, consider increasing the delay between REMOVE and ADD operations to allow for propagation time, or implement a retry mechanism that verifies permissions were added before proceeding. To help our engineers investigate further, please also provide: 1. Which PDP version you are running 2. Relevant logs from your PDP showing the timing of these operations 3. The exact
fetch()
code you're using for both the REMOVE and ADD calls
To learn more, see the sources I considered: [[1] Send Consistent Updates (Read-Your-Own-Writes)](https://docs.permit.io/how-to/manage-data/local-facts-uploader)
a
PDP: 0.9.5-rc.1
d
Hi @Ash are you seeing any errors or just not observing the results you expect? If so can you send over the errors you observe
a
@david logs in the other channel
e
Hi @Ash ,thanks for the details and for your patience. We've reviewed this on our side and haven't found any intentional changes to the add/remove permissions behavior. Our add-permissions API only returns a successful response (200) after the permissions have been persisted, so to help us narrow this down, could you please check a few things? 1. The POST response itself — the response includes the role and its full list of permissions. For a failing request, does the response already contain the permissions you just added? 2. A re-check after 30–60 seconds — if you fetch the role again via the API about a minute later, do the permissions appear? 3. The PDP logs — could you re-share them in this thread? We want to make sure we're all looking at the same set of logs. If possible, a timestamp (or a couple of timestamps) for a failing request would also be very helpful so we can correlate it with our logs. Thanks again for flagging it. 🙏