SendGrid V3 API子用户：API密钥与on-behalf-of使用疑问

为啥要用on-behalf-of头？ #

• 集中管权限更省心：主账户API密钥能统一管控所有子用户的绝大多数操作，不用给每个子用户单独创建API密钥，既减少密钥泄露的风险，也省了一堆维护的麻烦。
• 批量操作效率高：如果要给多个子用户做重复操作，比如改邮件模板、调发送设置，用主密钥加on-behalf-of头就能快速切换上下文，不用反复更换不同的子用户密钥。
• 审计溯源更清晰：主账户发起的操作会统一记录在审计日志里，追踪子用户操作来源更方便；而子用户自己的密钥操作日志只关联子用户，排查问题时可能要跨账户核对，比较繁琐。

为啥有些端点不支持on-behalf-of？ #

像POST /v3/verified_senders这种涉及核心身份验证的端点，SendGrid设计上就要求必须用子用户自己的API密钥发起请求，原因很直接：

• 验证发送者是子用户的核心身份资产，必须严格绑定子用户的独立权限，防止主账户越权修改子用户的验证信息，打乱子用户的发送身份体系。
• 这类操作直接关系到子用户的邮件发送信誉，必须由子用户自己的权限确认，避免主账户误操作影响子用户的正常发送能力。

该怎么选：用on-behalf-of还是子用户API密钥？ #

• 优先用on-behalf-of：绝大多数常规操作，比如发邮件、管理联系人、改模板这些，用主账户密钥加这个头更高效，管理起来也顺手。
• 必须用子用户API密钥：碰到明确不支持on-behalf-of的端点（比如验证发送者、子用户自身的API密钥管理），那就只能用子用户专属的API密钥来发起请求。

关于你碰到的问题 #

你用on-behalf-of调用POST /v3/verified_senders没效果是正常的，这个端点确实限制了必须用子用户自己的API密钥，主账户通过头信息代操作是不被允许的。

内容的提问来源于stack exchange，提问作者Ruairi McNicholas