API 评估应该回答客户是否能够可靠地检索预期证据，而不是示例请求是否返回 HTTP 200。首先定义工作流程：例如，导出一个客户收到的证据 汇总报告 进入私人证据存储，而不会丢失页面或混合租户。在验证其当前合同之前，避免假设任何指定产品提供此接口。
固定合同和边界
记录提供者、端点、API 版本、身份验证方法、租户边界、字段、分页规则和记录的限制。将报告的身份与其到达时间和涵盖的期间分开。指定 API 是否返回原始报告、标准化行或派生结果。这些是不同的证据群体，需要不同的协调规则。
GitHub 的 API 版本文档 说明了使用 X-GitHub-Api-Version 的显式版本选择。这是版本控制实践的具体示例，而不是 GitHub 导出的证据 DMARC 报告。对于实际评估，请在测试前将这些详细信息记录在可审查的合同说明中。本指南不提供供应商合同、端点或产品功能。
测试出处和字段
对于标准化行，保留报告者、报告 ID、原始期间、接收时间和源指纹（如果有）。在批准的保留控制下保留原始工件。 RFC 9990 是聚合报告结构的主要参考。方便的 JSON 模式无法将报告的计数转换为已传递消息的证明或恢复接收者从未提供的信息。
询问该服务如何表示部分摄取、格式错误的报告、更正的数据和缺失的收集周期。悄悄跳过的页面可能会使看似合理的指标出现错误。请求包含已知错误的样本，并将其与独立计数的输入进行比较，而不仅仅是由相同导出提供支持的另一个屏幕。
有意识地练习故障路径
测试多页结果、空结果、重复输入、共享时间戳的两条记录、撤销的凭据、跨租户请求和瞬态错误。遵循记录的继续链接或光标。用于速率限制、记录状态、相关标头和重试策略。 GitHub 的最佳实践 建议尊重速率限制信号并避免不受控制的并发；具体限制仍以实际服务合同为准。
假设第一页已存储，但第二页失败。第一个请求的 HTTP 200 不能证明完全导出是合理的；保留部分状态并使用提供程序支持的继续或重新启动过程。另外，当调用者缺乏该授权时，对另一个授权测试租户的成功身份验证请求仍必须被拒绝。这些假设案例测试了不同的要求：完整性和授权。
对于重试测试，请将记录的速率限制响应与永久权限失败区分开。 GitHub 的速率限制文档 解释说它可以报告 403 或 429 的速率限制，因此在不阅读其错误上下文和记录的标头的情况下，不要将每个 403 分类为永久不可重试。应用实际提供者的有界等待和重试规则。这里没有执行虚拟时钟、重启测试、供应商调用或实时访问控制检查。
决定什么是可以接受的
创建评估记录，列出每个所需的行为、获得的证据以及剩余的不确定性。将缺失的租户隔离或不可恢复的数据丢失视为停止条件。缺乏制作凭证不一定会妨碍文件评估，但它确实会妨碍声称已测试实时访问控制。
与服务所有者商定下一步：获取沙箱、实施受保护的适配器或将工作流程缩小到支持的导出。保留固定的合同和测试装置，以便以后可以评估提供商的变更。将产品特定的声明限制在记录和观察到的能力范围内；本指南未验证EmailAuth API 集成。