An HTTP 200 with errors present doesn't tell you the cause by itself. Our authorization refusals also come back as HTTP 200, and their extensions.code reads INTERNAL_SERVER_ERROR because that is the default code for an error that doesn't set its own. So a recognized error code mapped to TRANSIENT can't tell an authorization refusal apart from a server-side fault.

The details that do tell them apart are the error's message and path, which your safe projection currently drops. The path shows which field in the selection failed. To check which existing access the token has, send query { apiToken { workspaces { id name } } } with the same Bearer token. That returns the workspace or workspaces the token can reach, so you can confirm both services sit inside that scope. For a project token, send query { projectToken { projectId environmentId } } with the Project-Access-Token header instead.

A further unchanged request returned HTTP 200, one error path at the backend alias, and matched the exact documented authorization-denial wording. Our strict acceptance check remains blocked. What non-mutating existing-access check can identify why that field is denied?

None of the fields in that selection have their own authorization rule. latestDeployment, activeDeployments, rootDirectory, source, and service.repoTriggers (including checkSuites and repository) are readable at the same viewer-level access as the service instance itself, for both project and workspace tokens. So a "Not Authorized" error whose path stops at the backend alias, while frontend resolves, means the token cannot reach that service instance at all. It is not a denial of one sub-field.

To check this without changing anything, send query { backend: serviceInstance(serviceId: $back, environmentId: $environmentId) { id } } with the same token. If that minimal query is also denied, the problem is access to that serviceId and environmentId pair, not your field selection. Then compare that pair against the token's scope. Use query { apiToken { workspaces { id name } } } for an account or workspace token, or query { projectToken { projectId environmentId } } for a project token, since project tokens are limited to one environment. With user credentials, projectMembers(projectId: ...) { role } shows the role on that project.