Skip to main content
Quick Summary: The key authenticated and holds the right scope, but the acting person — the SkillsDB user the key acts as — does not have permission for this operation. Editing the key’s scopes will not help; bind the key to a person who can do this in the app.

​
What happened

Every operation requires two things: the key must hold a scope (like careers:write) and the person the key acts as must hold the matching permission in SkillsDB. The effective permission is always the intersection — a key can never do more than its acting person could do in the app. This error is the second half of that rule. Typical causes:
  • The acting person’s access level cannot perform the operation at all (for example, a Basic employee listing people).
  • The operation targets someone outside the acting person’s span of control (a manager-bound key reading a person who does not report to them — though where a resource exists in another company this is a 404, never a 403).
  • The acting person’s role forbids the specific write (for example, granting an access level above their own).

​
What to do

Bind the credential to a person with the right access level — an administrator does this under Settings → API Credentials — or adjust that person’s role in SkillsDB. Do not grant more scopes: a key whose acting person is denied is denied regardless of scopes.

​
When the workspace’s trial has expired

A request refused because the workspace’s trial has expired also answers 403 with this type, but carries two extra members: error set to "trial_expired", and an upgrade_url. Rebinding the key or changing roles will not help here — a workspace admin restores API access by upgrading at upgrade_url.
Check for error: "trial_expired" before treating a 403 of this type as a permissions problem.

​
How this differs from insufficient-scope

Branch on type, not on detail — the two remedies are opposites.