Hello, guys! Here at AllieHealth we've been going through a weird quirk we believe some version of the API seems to have introduced at some point: identically-named roles being assigned to the wrong resource type. Take this check, for example:

curl -sS -H "Authorization: Bearer $env:PERMIT_PROD_KEY" "<https://api.permit.io/v2/facts/default/production/role_assignments/detailed?user=12354&tenant=default&per_page=100>"

It returns something like:

{
  "id": "004242fee3b54d94a5f1caadd52b2ff4",
  "role": {
    "id": "865927aa193e40ebbb2a1bfec64de774",
    "key": "SchedulingExecutive",
    "name": "SchedulingExecutive",
    "permissions": [
      "Company:read-company",
      ...
    ]
  },
  "user": {
    "id": "0b7823e7c956452285e90375d7550e02",
    "key": "12354",
    "email": null,
    "first_name": ...,
    "last_name": ...,
    "attributes": null
  },
  "tenant": {
    "id": "463ab023370c43b6b383d2cced12afb4",
    "key": "default",
    "name": "Default Tenant",
    "attributes": null
  },
  "resource_instance": {
    "id": "00904ff7cbdc402aaf372e9ef1c444de",
    "key": "194",
    "resource": "Community",
    "attributes": { ... }
  },
  "organization_id": "75ba10ce33df4af49b3d3f28251ad325",
  "project_id": "06a201217bf34db08ced08463a3c1e68",
  "environment_id": "c2806df4431a49d49390e0d61fe1ee3e",
  "created_at": "2026-01-23T15:45:51+00:00"
}

Notice how the permissions given start with

Company:

, which all come from

Company#SchedulingExecutive

, but have been applied to

Community#194

as if they were

Community#SchedulingExecutive

because with the Node.js SDK we used to refer to it simply as

SchedulingExecutive

and expected the API to pick-up the correct resource type on Permit's side. Now, the problem is we're trying to fix these mismatches, both through the web UI panel or through the SDK/API; neither works (generally just a 404 or generic error message). Is this a known regression? If so, has it been patched at some point? And how to recover from it for existing users without having to recreate all? Thanks!

Hi @Luiz da Silva, I'm an AI assistant for Permit.io. I'll analyze available sources and get back to you shortly.

Hi folks, thanks for the detailed report; we'll review and circle back

Thanks, Or!

Hi @Luiz da Silva, thanks for the clear write-up. That curl output made this quick to track down. Short answer: yes, this is a known issue, we have already fixed what caused it, and we are working on cleaning up the records it left behind. Yours are on that list. In Permit, role names are unique per resource type. You can have a SchedulingExecutive on Company and a separate one on Community. An older version of our bulk-assignment endpoint looked roles up by name alone, so when the same name existed on two resource types it could pick the wrong one and attach it to the right object. That is exactly the mismatch you found: the assignment sits on Community#194, which is correct, but it points at Company’s SchedulingExecutive. Why you are getting 404s now? We fixed that endpoint in July, and part of the fix was making the API stricter. It now refuses to act on an assignment whose role does not belong to that resource type. That stops new mismatches from being created, but it also means the existing mismatched records no longer match when you try to remove or edit them, whether from the SDK or the dashboard. So the 404 is our own fix doing its job, on records that pre-date it. You cannot clear these from your side. Your permissions have been correct the whole time. When we evaluate an authorization decision we resolve the role by its name against the resource type of the object being checked, not by the internal link that is wrong here. So 12354 on Community:194 has been getting Community’s SchedulingExecutive, which is what you intended. The Company: permission list you see is our read API displaying the wrong linked role. Nobody has been given access they should not have. We have a repair that repoints these records at the correct role. We have already run it for several other customers. It does not change anyone’s permissions and there is no downtime. You have around 1,700 affected records across all envs. @david will coordinate a time with you for next week.

Sounds good! Thank you so much for the thorough response, I'll relay it back to my team then so that we can manually handle unassignments in the meantime.

@Ze'ev Manilovich Thanks for the clear explanation and for including us in the cleanup. I work with @Luiz da Silva, and this lines up with what we found. We’ve updated our integration to use the exact resource-scoped role ID for new assignments. Existing authorization appears to work as intended, but we need to be able to delete these assignments when access should be removed. We’d like to move forward with the repair to restore that ability. In the spirit of mitigating unforeseen issues, could we perhaps start with a small set and verify that existing permissions remain unchanged and role removal works before proceeding with the rest? We’re happy to coordinate those checks with you.

Yes @david will coordinate it for next week, and we can start with non prod envs, we are doing it with a backup and always btw.

Hi @khang @Luiz da Silva we'd like to proceed and fix these issues in your data. No downtime is expected and no action is needed from you, though as with any maintenance there is some inherent risk of service disruption. Because of this, we would like to coordinate this maintenance schedule with you. We'd like to run this on Wednesday September 23 @ 07:00 ET — please let us know if that window works for you.

That works, will keep watch. Let us know how it goes!

Hey All finished 🙂 If you come across any issues let us know

Thanks! Will look and report back!

@khang and @Luiz da Silva, are you guys aware that you have a script calls 100s of times delete bulk users every odd day at 00:00~ UTC ? I’m asking since this is a huge spike all at once every odd day, this is an unusual pattern in our monitoring system, and it creates a huge flood of data all at once. We handle it, but if you it grows a lot bigger it will be rate limited.

Hello, Ze'ev! Yes, we're aware: it's a script we use for keeping a sandbox environment in sync with our production one.

Can you make it run in several batches? since you are very close to rate limit

Back when we introduced it, we hadn't found a better way of syncing role assignments, in particular, but we're open to revisiting that approach if you guys have more lightweight APIs we can combine to achieve the same result.

Even if you spread it to several batches, it should be great. We have the Nexus PDP if you want to try it, but it doesn’t support ABAC yet (I didn’t check if you guys use it). The NexusPDP supports even 100s of millions of relations

Hi @khang and @Luiz da Silva if its possible to update it to multiple batches that would be great 🙏