An automation job reads device compliance from Catalyst Center with a dedicated service account and now receives an HTTP 403 response from Catalyst Center on one Intent API call, while the same request succeeds when the engineer opens the equivalent page as a super admin in the GUI. The token is refreshed on every run. Which authentication or permission issue should the engineer correct first?

The correct fix is to grant the dedicated service account read permission for the specific API category used by the failing Intent API call. The GUI succeeds because the super-admin account has broader privileges; that does not establish that the service account has equivalent access. A general read-only role can be a sensible least-privilege starting point, but it fails if that role does not include the relevant API category—broad-sounding read access is not proof of category-level authorization. Regenerating OAuth credentials with a read scope is a common remedy in systems whose API authorization uses OAuth scopes, but it does not address Catalyst Center's role-based permission assignment in this scenario; the token is already refreshed, and the missing authorization is tied to the service account's role. An API allowlist can explain a 403 in some deployments, but the response shows the request reaches the controller, and the evidence points first to the service account's API permissions rather than a source-address rule. Exam caveat: a 403 identifies an authorization failure broadly, not necessarily the exact permission layer, so confirm the controller's RBAC model and logs before changing access. Practical check: inspect the service account's assigned role and verify that its permissions explicitly include read access to the failing Intent API category.