I’m building an integration on the v2 Web API (https://api.sonarcloud.io) and I need to list the users in an organization, but GET /users/users always returns a 403 and I can’t find a way to make it succeed.
My setup:
Organization on the Team plan, bound to GitHub.
Calling account is the organization admin (Administrator + all org permissions).
With the same credentials, here’s what I see across endpoints:
GET /organizations/organizations → 200, returns the org (including its uuidV4).
GET /users/roles?organizationId= → 400, “Missing required request parameters: [principalIds, principalType, resourceType]” — so it authorizes fine.
GET /users/users?organizationIds= → 403, “User is not authorized to access this resource with an explicit deny in an identity-based policy”.
Things I’ve already checked/tried:
Confirmed the organizationIds value and its casing.
Tried both a Personal Access Token and a Scoped Organization Token — same 403 with each.
Upgraded the org from Free to Team — no change.
The same token clearly works on the other endpoints above, so it seems specific to /users/users and happening at the authorization layer.
What do I need in order to call GET /users/users successfully? Is there a required plan, permission, or token type for this endpoint that I’m missing, or is there something else about how it’s authorized that I should know?
I wasn’t able to reproduce the 403 on my end with a Free or Team plan and Org admin credentials. There’s no specific plan tier or additional permission required for this endpoint, Org admin access should be sufficient.
I’d like to narrow down what’s different in your setup. A few things that would help:
Generate a fresh token and test immediately — create a brand-new PAT or SOT right now and use it directly, without copying from a password manager or any intermediate step. Even a single invisible character or trailing newline in a token can produce exactly this kind of auth failure. Changing a character in the token was enough to generate a 403 in my testing.
Share the exact request you’re making — a curl equivalent with the token masked (e.g. abc...xyz) would help. Specifically, I want to confirm how you’re passing the token (header name and format) and the exact organizationIds value you’re sending.
Any proxy or VPN in the path? — if your requests go through a corporate proxy, WAF, or VPN that could rewrite or strip headers, that would explain why the same token works on some endpoints but not this one.
Full response including headers — if you can share the complete response (body + headers) for the failing request, there may be a request ID we can use to trace it on our side.
Try with no query params — what does GET /users/users return with no organizationIds at all?
The /users/users issue is resolved now — it works successfully with an org admin PAT, and I can list the organization users.
The remaining issue is with /users/roles.
This request:
GET /users/roles?organizationIds=<org_uuid>&resourceType=ORGANIZATION&principalIds=<user_id>&principalType=USER
returns:
{
“message”: “Roles management for users and groups is not available.”
}
The org is on Team plan, bound to GitHub, and the same PAT works for /organizations/organizations and /users/users.
I’m specifically testing direct user roles/permissions here (principalType=USER), not group membership management.
Could you clarify what this error means? Is /users/roles expected to work on Team plan, or does it require Enterprise / another entitlement / a non-GitHub-bound org?
I dug into this a bit deeper. The error is by design since /users/roles is only designed to be used for managing Scoped Organization Token (SOT) permissions. It’s designed to configure which resources a token can access and with what role. The property principalType only works with the organizationToken value.
The other values, groups or users is not available to external callers regardless of plan. User and group principal types are reserved for internal use only.
If your goal is to read or manage user/group permissions on an organization or its projects, you could try the v1 API api/permissions/*.
I’ll flag this for our internal teams to see if we can add more clarity to our API spec documentation on the users/roles endpoint
I’m building an integration on the v2 Web API (https://api.sonarcloud.io) and I need to read/manage organization-level roles or permissions for users, but GET /users/roles returns “Roles management for users and groups is not available.”
My setup:
Organization on the Team plan, bound to GitHub.
Organization response shows subscription: “PAID” and enterpriseFeatures: false.
Calling account is the organization admin.
Authentication is with a Personal Access Token generated by that admin user.
With the same credentials:
GET /organizations/organizations → 200, returns the org including uuidV4. GET /users/users?organizationIds=<org_uuid> → 200, returns org users including their user ids.
When I call the roles endpoint for a direct user:
GET /users/roles?organizationIds=<org_uuid>&resourceType=ORGANIZATION&principalIds=<user_id>&principalType=USER
I get:
{ "message": "Roles management for users and groups is not available." }
To clarify, I’m testing direct user roles/permissions here, not group membership management: principalType=USER.
What does this error mean? Is GET /users/roles expected to work on Team plan, or does it require Enterprise / enterpriseFeatures / another entitlement? Does the organization being GitHub-bound affect this endpoint?
If /users/roles is not the right API for this use case, what is the supported way to read, add, or remove organization-level permissions for a user?
Hi Stevan, thanks for pointing me to the v1 api/permissions/* API. I did get permission reads working with these two endpoints:
GET api/permissions/users?organization=
GET api/permissions/groups?organization=
Both return the data I need (each user/group with their permissions list).
The thing is, I can’t find any documentation for them — they don’t show up in the Web API explorer, and they’re not listed in api/webservices/list either. I actually only found them with the help of Claude (which knew them from older SonarQube versions), and then confirmed they still respond on Postman.
So I wanted to check: are these the endpoints you meant? And since they’re undocumented, are they safe to rely on, or is there a documented/supported way to read user and group permission assignments that I should use instead?
