Subject: Custom App (Client Credentials Grant) blocked from downloading file content despite correct scopes, collaboration, and verified impersonation
Enterprise ID: 290084
Enterprise name: Simplexity Services
App name: WebData
App ID: 2633167
Client ID: 81jcl8rh4t3pc2b22z05n5rcumo5x4lk
Authentication type: Client Credentials Grant (Server Authentication)
Service Account: [removed by moderator] (user id [removed by moderator] )
SUMMARY
My Custom App's service account can successfully authenticate, list folder
contents, and read file metadata, but every attempt to download actual file
content via GET /2.0/files/{id}/content returns:
HTTP 403
{"type":"error","status":403,"code":"access_denied_insufficient_permissions",
"message":"Access denied - insufficient permission"}
This happens even when the request impersonates a full co-owner of the
enterprise via the As-User header, so it does not appear to be a
permissions/ownership/collaboration issue on any specific file or folder.
I believe this is an enterprise-level content security or governance policy
blocking API-based content downloads, but I cannot find where that setting
lives, since every app-level configuration option checks out as correct
(details below).
WHAT I'VE ALREADY VERIFIED AS CORRECT
1. App is Authorized (Admin Console shows "Authorization Status: Authorized").
2. App is Enabled ("Enablement Status: Enabled").
3. App Access Level is set to "App + Enterprise Access" (Admin Console shows
"App Access: All Users") — changed from the original "App Access Only"
specifically to rule out an ownership restriction, then re-authorized.
4. App Scopes include "Read all files and folders stored in Box" (confirmed
in Admin Console's App Scopes list, alongside Manage groups/users/app
users/enterprise properties).
5. The app is on the enterprise's Application Restrictions allowlist.
6. The service account ( [removed by moderator] )
is an accepted Viewer collaborator on the parent folder
("02 Simplexity Services Clients", folder ID [removed by moderator] ) — confirmed via
the Content Manager API, status: accepted, isActive: true.
7. "Make API calls using the as-user header" is enabled.
8. Calling GET /2.0/users/me with header "As-User: [removed by moderator] " (my own user
ID, a full Co-Owner on every relevant folder) correctly returns my own
identity (200, name: Frederick Morrison) — proving impersonation is
genuinely active, not silently ignored.
9. With that same As-User header, GET /2.0/folders/ [removed by moderator] /items
succeeds (200) and lists all 44 client subfolders.
10. With that same As-User header, GET /2.0/files/{id}/content STILL
returns 403 access_denied_insufficient_permissions — on multiple
different files, in multiple different subfolders, despite acting as
a Co-Owner of the entire tree.
STEPS TO REPRODUCE
1. POST https://api.box.com/oauth2/token
grant_type=client_credentials
client_id=81jcl8rh4t3pc2b22z05n5rcumo5x4lk
client_secret=<redacted — on file, can provide securely if needed>
box_subject_type=enterprise
box_subject_id=290084
-> returns valid access_token
2. GET https://api.box.com/2.0/files/ [removed by moderator] /content
Header: Authorization: Bearer <token>
-> 403 access_denied_insufficient_permissions
(box-request-id: 1f6f8f65bf710cfc83b71d33809a8ec89)
3. Same call, but adding: As-User: [removed by moderator] (my own user id, verified via
/users/me to correctly impersonate me)
-> STILL 403 access_denied_insufficient_permissions
(box-request-id: 031730cf0b513dd8838f080a66bf04767)
4. For comparison, GET https://api.box.com/2.0/files/ [removed by moderator]
(metadata, no /content) with the exact same headers -> 200 OK, full
metadata returned correctly.
Additional box-request-ids from repeated tests of the same failure, for
your reference in server-side logs:
- 0b4851e49ccd7b937bd10ce696e85e14b
- 15575c619448c3e7d4609553a56fe182a
- 02908678bc8f80e1d2bccb202e00dd9bb
- 071f3743649c7e2e5cd499e75483eba95
QUESTION FOR BOX SUPPORT
Given metadata/listing succeed and content download fails identically
regardless of identity (service account or impersonated Co-Owner), is
there an enterprise-level policy (Shield, content security, download
restriction, or similar) that specifically blocks the /content endpoint
for Platform App / Client Credentials Grant traffic on this enterprise?
If so, where can an enterprise admin locate and adjust it? If this is
unexpected behavior, please advise what additional configuration is
required to allow content downloads.
Enterprise admin available to assist: Greg Arnold ( [removed by moderator] )
Developer/app owner: Frederick Morrison ( [removed by moderator] )