我是大明。这次，我为 Simbatch 配置了 Facebook 广告数据连接器，应用名称是 Simbatch Ads Connector。过程里既有创建应用、选择权限，也遇到了一次权限报错。随后，我使用用户访问口令，在 Meta 图谱 API 探索工具里读到了目标广告账户的信息和广告报表。
先把结果说清楚：/me/permissions 返回 ads_read 和 public_profile 已获授权；指定账户返回币种 USD、时区 Asia/Shanghai；账户级 Insights 返回了 2026 年 10 月 26 日至 11 月 1 日的消耗、展示和点击数据。之后，我延长了访问口令期限，页面显示新口令将于 2027 年 1 月 1 日到期。
下面按实际操作顺序，把创建入口、遇到的问题、检查方法和最后的返回结果写下来。本文记录的是这次接入配置与 API 读取验证，方便后续把同一套核对方法用于 Simbatch 的数据接入。
一 为什么要做这次广告账户接入
我希望把广告消耗、展示和点击这些基础数据，和团队日常使用的店铺、商品、素材记录放在一起看。对接之前，先要解决一个具体问题：使用当前应用和访问口令，能不能读到正确广告账户的数据。
所以，这次我先做读取验证。用哪个应用、选择哪种口令、口令里有什么权限、返回的是哪个账户，都逐项核对。等这些环节清楚了，再处理系统中的保存、定时同步和报表展示。
此前我也整理过 Shopify 与广告平台的连接过程：
Shopify 如何连接 ChatGPT Ads？我的美国店铺账户与像素绑定实录
这篇接着记录 Facebook 广告数据这一侧的配置。两篇对应不同平台，具体入口和授权方式分别以各自的操作过程为准。
二 创建 Simbatch Ads Connector 应用
我先进入 Meta for Developers 的“我的应用”，开始创建应用。创建向导上方依次是“应用详情”“用例”“业务账户”“要求”和“概览”。
第一步填写应用名称和联系邮箱。我为这次连接器使用的名称是 Simbatch Ads Connector，联系邮箱是 support@simbatch.com。图 1 保存的是刚进入表单时的画面，当时名称框还没有填入内容；创建完成后的应用名称，可以在后面的控制面板中核对。
接着进入“添加用例”。这次使用的是“用市场营销 API 创建和管理广告”。页面里还有一项“用 Meta 广告管理工具创建并管理应用广告”，它的说明明确写着不包含市场营销 API 的访问权限，所以这里要看清用例名称。
按照向导继续选择对应的业务资产组合、查看要求并核对概览后，我完成了应用创建。随后进入控制面板，左上角已经显示 Simbatch Ads Connector，中间出现“定制‘用市场营销 API 创建并管理广告’用例”的入口。
这时左侧“发布”旁边显示“未发布”。我接下来继续做权限和数据读取测试，没有把创建完成当作应用已经对外发布。
三 查看权限列表并核对应用基本信息
在控制面板里进入市场营销 API 用例的定制页面，我查看了“权限和功能”列表。这里的 ads_management、ads_read 和 business_management 都显示“准备测试”；Marketing API Access Tier 则显示“有限访问权限”。
我这次的目标是读取广告数据，因此后面重点检查 ads_read。权限列表里出现某一项，和当前访问口令实际获得这一项授权，需要分别核对。真正生成口令后，我还会通过 /me/permissions 查看授权结果。
接着，我打开“应用设置 > 基本”。这里可以核对应用编号、显示名称和联系邮箱，右侧是应用密钥区域，默认以圆点隐藏，并提供“显示”按钮。
同一页也提供应用域名、隐私政策网址、服务条款网址等字段。这张画面中，这些网址栏还显示提示文字。我把当时的状态保留下来，避免把进入设置页和已经填写保存混为一步。
四 第一次读取遇到权限报错
进入图谱 API 探索工具后，我尝试读取目标广告账户的基本信息，请求版本选择的是画面中的 v26.0。返回结果没有给出账户信息，而是出现 OAuthException，错误码为 200，提示涉及 ads_management 或 ads_read 授权。
回看这张图，右侧“用户或公共主页”位置选择的是“应用口令”。后面读取成功的几张图，这个位置已经变成“用户口令”。这是本次排查中值得一起核对的两个画面：不能只看到已经生成一串口令，就直接认为它能读取目标广告账户。
我随后继续处理用户口令配置与权限选择。在“选择权限”页面，勾选的是 ads_read；同一列表中的 ads_management、business_management 等选项没有勾选。页面也提示，这项配置选择了使用用户访问口令。
五 用实际返回结果确认口令权限
配置后，我回到图谱 API 探索工具，核对选中的应用，并使用“用户口令”。先执行一个权限查询：
GET /me/permissions这次返回的 data 中，ads_read 和 public_profile 两项的 status 都是 granted。到这里，当前用户口令的授权结果才有了直接的接口返回依据。
这里记录的是本次口令的实际范围，不能把前面应用权限列表里的所有项目都算进来。尤其是 ads_management，虽然出现在应用的权限列表中，但这次权限查询没有返回它。
六 读取指定广告账户的基本信息
确认权限以后，我继续读取目标广告账户，查询的字段是 id、name、currency 和 timezone_name。下面将实际账户编号替换为“你的广告账户ID”，保留本次请求的写法：
GET /act_你的广告账户ID?fields=id,name,currency,timezone_name
这次返回了账户编号、账户名称、USD 币种和 Asia/Shanghai 时区。我先核对目标账户，再看数据本身，这样后续处理多广告户时，不容易把不同账户的数据混在一起。公开配图中的账户编号、名称和访问口令已经遮挡。
七 继续查询账户级广告报表
基本信息读取成功后，我继续查询这个账户的 Insights。请求字段包括 account_id、account_name、spend、impressions 和 clicks，日期条件选择 last_7d，查询层级为 account。
GET /act_你的广告账户ID/insights?fields=account_id,account_name,spend,impressions,clicks&date_preset=last_7d&level=account上面为便于阅读进行了换行；实际输入请求路径时合并为一行，并替换为自己的目标账户编号。
本次接口实际返回的数据如下。金额按前一步确认的账户币种 USD 记录，日期按响应里的 date_start 和 date_stop 记录。
| 字段 | 本次返回值 |
|---|---|
| 统计开始日期 date_start | 2026-10-26 |
| 统计结束日期 date_stop | 2026-11-01 |
| 消耗 spend | 281.65 USD |
| 展示 impressions | 7,545 |
| 点击 clicks | 260 |
这一步已经能确认：当前应用和用户口令可以读取这个广告账户的基础报表。这里的 clicks 是返回的点击字段，本次没有请求订单、销售额或 ROAS，所以不据此判断广告盈利情况。
八 检查访问口令状态和到期时间
完成读取测试后，我打开“访问口令调试工具”，粘贴当时使用的口令并点击“调试”。页面列出了应用信息、口令类型、到期日、有效状态和范围。
这次口令类型是 User，“有效”一栏显示“真”，范围显示 ads_read、public_profile；到期日旁边的相对时间提示是“约 1 小时后”。这些是我当时这枚口令的状态，后续操作时要检查自己页面上的实际时间。
这里也要分清两个字段：“有效：真”说明调试工具显示当前口令有效，权限范围则看“范围”这一栏。它们分别回答口令是否有效、具有什么授权，不能把“真”直接理解为某项权限的名称或授权结果。
九 延长访问口令期限并核对新口令
在调试结果下方，我点击“延长访问口令期限”。页面随后增加了一个新区域，显示一枚新的长期有效访问口令，并明确提示它将在 2027 年 1 月 1 日过期。
这张图里，上方旧口令信息仍然保留“约 1 小时后”的提示；下方新生成区域另有到期日期。查看结果时要看清对应的是哪一枚口令，后续配置也要核对使用的是新生成的那枚。
长期有效仍有到期日。这次我能确认的是页面生成了新口令，并显示上述期限；不能因此把它当成永久口令，也不能把前面使用旧口令完成的读取测试，直接当作新口令已经完成同样的验证。
十 这次操作完成到哪一步
这次我完成了连接器应用创建、用户口令权限核对、目标广告账户基本信息读取和账户级 Insights 查询，并在调试工具中生成了期限更长的新口令。操作过程里遇到的权限错误，也和后面的成功返回一起保留了下来。
对 Simbatch 来说，这些结果提供了继续接入的基础。要把它变成后台持续可用的数据，还需要使用新口令重新测试，确认连接器读取、数据保存、定时同步和后台展示等后续环节。这篇案例记录到已经实际验证的 API 返回与口令延长结果。
常见问题
应用权限显示准备测试 就代表口令已授权吗
不能只看这一处。本次应用列表中有多项“准备测试”，而 /me/permissions 实际返回的是 ads_read、public_profile 两项 granted。我还继续读取了目标账户和 Insights，确认这个账户的调用结果。
这次使用的是应用口令还是用户口令
报错截图中选中的是应用口令；后面成功返回权限、账户信息和报表的截图中，选中的是用户口令。调试工具也显示类型为 User。
这次有没有申请广告管理权限并修改广告
本次权限选择勾选的是 ads_read，展示的接口操作都是 GET 查询。本文没有创建、暂停广告或修改预算的操作记录。
延长后的口令是不是永不过期
不是。这次页面明确显示新口令将在 2027 年 1 月 1 日过期。要按实际口令的状态和到期时间维护，不能省略这一步核对。
读到报表就代表 Simbatch 自动同步已经完成了吗
本次成功返回发生在图谱 API 探索工具中。Simbatch 的实际保存、同步任务和前端展示，需要在系统中继续验证。接口返回成功是接入过程中的一个明确结果。
关于大明与 Simbatch
我是大明，持续记录独立站运营、广告投放和 Simbatch 系统建设中的真实操作。这次把应用配置、权限检查、报错和接口结果放在一起，后续遇到类似接入任务，团队就可以沿着同一条检查顺序逐项核对。
相关阅读
- Shopify 如何连接 ChatGPT Ads？我的美国店铺账户与像素绑定实录
另一篇广告平台与店铺连接的实际操作记录。
- 官网如何接入 Google 收录和流量统计？Simbatch 实操记录
查看官网收录和访问数据的配置与检查过程。
- AI 如何从团队积累中学习？
了解如何保留来源、确认与反馈，让业务记录在后续工作中继续发挥作用。