LinkedIn API v2调用read_assets返回401 ACL报错，求解决办法

安全阿岳

2026-5-13

解决LinkedIn API v2 401 Tenant ACL错误的排查方案

我之前帮团队排查过一模一样的LinkedIn API v2 401错误，结合实际踩坑经验和官方要求，给你几个核心排查方向：

核对数字媒体租户URN的正确性
错误日志里提到的urn:li:digitalmediaTenant:11是关键。你需要确认这个租户URN是否和你的应用在LinkedIn开发者后台关联的数字媒体租户完全一致。很多时候是调用时误填了测试环境的租户ID，或者搞混了不同应用的租户信息——去后台的「媒体管理」板块就能找到你的正确租户URN。
确认应用是否获得read_assets对应的权限
虽然你的应用已获批使用v2端点，但LinkedIn的API权限是细分到具体操作的。read_assets操作对应的权限是r_mediaassets，你需要去开发者后台的「应用权限」页面检查是否已申请并获批这个权限。如果没有，得补充提交权限申请，这个审批一般1-2个工作日能完成。
验证访问令牌的权限和有效性
确保你用来调用API的访问令牌包含r_mediaassets权限。可以用LinkedIn开发者后台的令牌验证工具，输入令牌就能查看它的权限列表。另外还要检查令牌是否过期，如果是用户授权的令牌，还要确认用户没有撤销对你应用的授权。
检查API调用的参数和端点合法性
要保证调用read_assets的端点路径正确（比如正确格式是/v2/assets/{assetUrn}），并且assetUrn对应的资源确实属于你的租户URN。LinkedIn不允许跨租户访问其他应用的媒体资源，所以如果assetUrn归属的租户和你调用时指定的不一致，也会触发这个ACL错误。
联系LinkedIn开发者支持
如果以上所有排查都没问题，但错误依然存在，大概率是后台的ACL配置出现了异常。这时候你可以在开发者后台提交支持工单，附上完整的错误日志、你的应用ID、租户URN以及API调用的详情，让LinkedIn的技术团队帮你核对后台权限配置。