我的案例

每到月底，行政都要做同一件事：把钉钉的打卡记录导成表，再对着请假单、加班单一条条核。核对的过程不难，难的是重复——上个月核过的规则，这个月还得从头来一遍。

钉钉里并不缺数据，缺的是一条把它自动送进自己系统的通道。勤哲 Excel 服务器从 19.1.11 起提供 WebAPI 能力，可以直接调用外部接口取数，打卡记录就是最常见的用法之一。

下面这条流程是完整跑通过的：在钉钉建应用换凭证，把接口写进勤哲，再用表间公式把数据拉进模板。全程不写代码，需要的是对方文档、勤哲的配置，以及一张接数的表。

第一样是版本。勤哲系统套餐需为套餐 7，小版本更新到 19.1.11 或更新，低版本里找不到 WebAPI 入口，后面的步骤无从谈起。

第二样是账号。要能登录钉钉开放平台，并且有权限创建企业内部应用——查看 AppKey、重置 AppSecret 这些动作通常只有管理员能做。

再准备一个接口调试工具会更省事。钉钉的文档更新往往慢于接口实际返回，先用工具打一次，看清真实返回的字段，再去填勤哲里的返回参数，比反复试错快得多。

钉钉的每次接口调用都要带一个 access_token，它是调用者的临时通行证。要拿到它，得先有一个企业内部应用作为身份。

在开放平台创建应用后，应用详情里能看到 AppKey 与 AppSecret。前者是身份编号，后者相当于密码，只应保存在服务端，不要写进任何会发给别人的表格里。

回到勤哲的设计界面，新增一个 WebAPI。要填的东西归成四组：接口地址、调用方法、请求参数、返回参数。地址只写到问号之前，后面的查询串交给参数表。

获取 token 的接口用 GET 方法。请求参数按钉钉文档填，参数名必须与文档完全一致，大小写不同也会认证失败。返回参数可以直接从文档复制粘贴，再按实际返回结构删掉多余的层级。

配置好之后，用一张单独的模板去执行取 token 的公式，把结果存下来。token 有有效期，过期要重新取，所以这张表的作用是"存着最新的一份"，供其他公式调用。

这张表要加两道保护：字段设成不可编辑，显示格式设成隐藏。token 一旦在界面上明文露出来，等于把接口钥匙交给了所有能打开这张表的人。

取打卡记录前先读文档。钉钉的考勤接口和企业微信有一处明显不同：起止时间不需要换算成 Unix 时间戳，可以直接填日期时间；但两个时间之间的间隔不能超过七天。

这意味着按月一次取是不行的。做法是按周切片，让公式一次取七天，多跑几次；或者在模板里放一个起始日期，每次执行后自动往后推七天。

接着新建第二个 WebAPI，专门取打卡数据。地址、方法、请求参数照文档填，access_token 作为参数之一传入，取的是上一节存下来的那一份。

返回参数这一步最容易踩坑。钉钉文档里写的字段和接口真实返回的字段偶尔不一致，照抄会解析失败。稳妥的做法是先用调试工具打一次，把真实返回的 JSON 复制进勤哲，让它自动识别。

数据取回来要有地方放。新建一张模板，字段按打卡记录设计：工号、姓名、打卡时间、打卡类型、考勤结果。字段名不必和接口一致，但类型要对得上。

模板页面上放几个参数格：起始日期、结束日期、用户 ID。这些格子的值会被公式引用，改一次就能换一个查询区间，不必每次进设计界面。

公式配好，执行一次就能看到结果：选定区间内的打卡记录按行填进明细表，字段对齐，不需要人工再整理。录屏演示里完整的动作只有三步——打开模板、点执行、等几秒。

要留意接口的分页限制。钉钉某些接口一次只返回 50 个员工、50 条记录，人数多的时候需要多次提取，公式要按返回的总数循环，或者手工改区间再跑一次。

把流程抽象出来，其实是三步：读对方文档、在勤哲建 WebAPI、在模板里用表间公式取数或回写。钉钉只是其中一种，企业微信的打卡接口走的是同一套逻辑，差别在时间戳格式和调用方法。

再往外扩，金数据、问卷星、提供 API 的 ERP 系统，都能按这个套路接进来。会配置一次，后面每接一个系统都省一半时间。

真正的门槛不在技术，而在字段口径。接口返回的"打卡结果"和人事口径里的"出勤"往往不是一回事，这层换算要写在表间公式里，写清楚了，取回来的数才能直接用。