Beta GRAPH API获取Schedule.TimeCards打卡数据：控制台应用报Bad Request

• 确认Graph客户端的API端点配置。当前开发基于Beta版本接口，需检查初始化graphClient时的BaseUrl是否设置为Beta端点地址，若默认指向v1.0正式版端点，由于Teams TimeCards接口暂未在v1.0版本开放，请求会直接触发Bad Request报错。
• 核对应用配置的权限匹配度。Graph Explorer能正常返回数据，是因为其交互授权流程的权限范围与控制台应用的权限配置存在差异：
  • 若控制台应用使用客户端凭据流（无用户登录），需在Azure AD应用注册页配置应用级的Schedule.Read.All权限，且完成全局管理员同意流程
  • 若控制台应用使用委托流（代用户发起请求），需确保获取的访问令牌中包含Schedule.Read.All委托权限，权限范围缺失时接口校验不通过会返回400错误
• 补充接口要求的一致性头部。Teams Schedule相关Beta接口依赖最终一致性存储，需在请求中主动附加ConsistencyLevel: eventual头部，缺省情况下接口会拒绝请求。可以通过SDK的链式方法补全头部，示例代码如下：

var timeCards = await graphClient.Teams[teamID]
    .Schedule
    .TimeCards
    .Request()
    .WithHeader("ConsistencyLevel", "eventual")
    .GetAsync();

• 校验团队ID的准确性。Beta版本接口对路径参数的校验更严格，若传入的ID是错误的Azure AD组ID、自定义团队标识（而非Teams实体本身的ID），会直接返回Bad Request而非更明确的404错误。可通过团队列表接口拉取对应团队的原始ID值替换测试，不要手动拼接ID内容。
• 确认团队排班功能已启用。如果目标团队未在Teams管理中心开启Shift排班能力，团队下不存在关联的Schedule实体，调用TimeCards拉取接口也会触发报错。可先单独调用Schedule根接口，确认返回的Schedule对象enabled属性为true，若为关闭状态需先开启排班功能再重试。

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