A read-only automation account runs a script that reads the device inventory successfully, then fails when it posts a new site to the Intent API. The token endpoint returned HTTP 200 and the same header carries the token on both calls, yet the create request comes back with HTTP 403. Which Catalyst Center permission condition explains that 403 response?

The correct condition is that authentication succeeded, but the caller’s assigned role does not grant the site-creation permission. A successful token response and successful inventory read show that the caller can authenticate and has at least some authorized access; they do not imply permission to perform every operation. Creating a site is a separate write action, so Catalyst Center can accept the token and still return 403 when the role lacks that action. The OAuth-scope explanation is a familiar pattern in systems built around scoped OAuth tokens, but it does not identify the Catalyst Center role permission at issue here; the scenario supplies no evidence of a missing OAuth scope. An API-service policy denying access could also produce a 403 in some deployments, but it asserts a separate restriction rather than the stated role condition, and nothing in the prompt indicates such a policy. A network allowlist may block requests in some environments, but it is a network-access control, not the caller’s Catalyst Center permission condition, and the prompt gives no evidence of a source-specific restriction. Exam caveat: HTTP 403 generally indicates that the request was understood but access was refused; it does not, by itself, prove which authorization layer refused it. In practice, check the account’s effective role permissions for the specific site-create operation and any applicable scope or policy, then correlate the result with Catalyst Center authorization logs.