Could someone explain the specific validation requirements for the POST /api/v2/screenshare/recordings endpoint when operating under a Partner App context with multi-tenant OAuth integration. We are currently developing a premium AppFoundry application that aggregates screen recording metadata across multiple client organizations. The integration relies on the standard OAuth 2.0 client credentials flow to obtain a service account token, which is then exchanged for a tenant-specific access token using the /api/v2/oauth/token endpoint with the grant_type set to urn:ietf:params:oauth:grant-type:token-exchange.
The issue manifests consistently when attempting to fetch recording details for sessions that occurred more than 24 hours ago. The initial token exchange succeeds without error, and the resulting JWT contains the correct purview_id and role assignments for the target organization. However, subsequent GET requests to /api/v2/screenshare/recordings/{id} return a 422 Unprocessable Entity response. The error payload indicates a validation failure on the ‘purview’ field, specifically stating that the provided purview ID does not match the token’s scope, despite the token clearly listing the correct organization ID in the purviews claim.
This behavior is intermittent and seems to correlate with the age of the recording session. Recent recordings from the last hour retrieve successfully, suggesting a potential caching or propagation delay in the purview validation service. We have verified that the service account has the ‘admin:screen_recording’ and ‘read:screen_recording’ permissions enabled in the AppFoundry configuration. The problem persists across both the US1 and EU1 environments, ruling out a region-specific outage.
Has anyone encountered similar purview mismatch errors when using multi-tenant OAuth tokens for historical data retrieval? We are considering implementing a retry mechanism with exponential backoff, but we suspect there might be a fundamental misunderstanding of how purview scopes are resolved for older recording artifacts versus real-time session data. Any insights into the expected latency for purview propagation or known limitations with the token exchange flow for archival data would be greatly appreciated.