Google My Business API：能做什么、需要什么以及边界在哪里
许多团队仍把现在的 Business Profile APIs 称为 Google My Business API。集成可以帮助管理地点资料和评价，但需要获批准的项目、真实认证与授权、合法业务理由，并严格遵守政策。它不是用来操作他人资料或绕过界面的公开 API。
快速回答
先阅读 Business Profile APIs 文档，确认用例和账号符合当前访问条件。配置 Google Cloud 项目、所需 API 和 OAuth，只申请必要范围，并在写入前验证请求。围绕真实失败设计同步、重试和幂等，不要承诺 API 自动覆盖所有地点或功能。
负责任集成的层面
复杂性不只是调用 endpoint，还包括证明谁授权、操作哪个对象、失败如何恢复以及政策如何限制使用。
| 层面 | 技术问题 | 生产控制 |
|---|---|---|
| 访问 | 项目和企业是否符合 Google 当前 API 访问要求？ | 在承诺客户集成前检查审批、文档和限制。 |
| 身份 | 每次操作由哪个账号、组织、地点和角色授权？ | 保存用户、账号和地点关系，不使用无范围的全局凭证。 |
| OAuth | Token 是否安全获取、存储、刷新和撤销？ | 加密秘密、限制 scope、轮换凭证，并提供明确断开入口。 |
| 数据 | 读取或写入哪些资源和字段，频率如何？ | 定义 schema、分页、限制、缓存和对账，把外部响应视为不可信输入。 |
| 事件 | 如何发现新评价、变更或发布失败？ | 使用有文档支持的通知或轮询、去重、退避和可观察队列。 |
| 政策 | 产品是否只操作企业拥有或获授权管理的资料？ | 拦截未授权账号，记录同意，并在开启写入前复查政策。 |
评估 API 的技术路径
这个流程可以避免演示在权限、规模、撤销或政策环节失败。
定义准确用例
区分读取地点、读取评价、回复、管理信息、接收通知和报告。不同操作可能有不同 endpoint、权限和限制。
检查访问和政策
阅读基础设置、常见问题和政策页面。确认组织对每个资料都有合法理由和授权，文档不能替代这份证明。
按地点建模授权
建立用户、账号、地点和 scope 的关系。有效会话不代表能访问所有地点，展示数据或开启回复前要确认所有权和角色。
设计失败和并发
区分处理 401、403、404、409、429 和临时错误。在适用时使用幂等或去重、带抖动退避、超时和不会重复发布的队列。
测试对账和撤销
模拟 Token 撤销、地点删除、评价编辑、重复回复和 API 不可用。定义重新授权、修复状态和断开连接，同时保留审计记录。
连接生产前的清单
集成是授权和数据产品，不只是一个连接页面。
用例允许。 企业有合法业务理由，只管理拥有或获授权管理的资料。
项目准备好。 所需 API、审批和配置都已记录并验证。
最小 scope。 OAuth 只申请需要的权限，用户可以撤销或断开。
租户隔离。 每条评价、回复和地点都绑定正确商家，不存在跨客户泄露。
具备韧性。 有超时、有限重试、退避、去重、限流和可见的操作员状态。
有审计记录。 记录谁授权、读写了什么、何时发生、结果和修复路径。
可靠集成指标
先衡量安全、一致性和成本，再追求数量。一个返回 200 却混淆地点的 API 集成仍然是坏的。
| 指标 | 技术解释 |
|---|---|
| 有效授权 | 按组织、scope 和最后使用时间统计连接，不保留不必要的 Token。 |
| 按类型的错误 | 分开权限、数据不存在、限额和临时故障，以触发正确响应。 |
| 避免重复 | 衡量事件或回复的幂等与去重，而不只是请求数量。 |
| 延迟和配额 | 观察 p95、限流和每个地点的运营成本，调整并发和缓存。 |
| 对账 | 比较本地与远程状态，衡量发现和修复偏差的速度。 |
| 已发布操作 | 记录可验证成功及授权关系，不要与排名或转化混淆。 |
场景与决策
使用这张矩阵把指南应用到实际情况中。每一行都把可观察的问题与更稳妥的行动分开，避免把假设写成承诺。
| 场景 | 可能发生什么 | 建议决策 |
|---|---|---|
| 访问权限 | Business Profile API 并不是任何项目都能未经审批直接使用的公开接口。 | 设计集成之前，先确认访问权限、合理用途和已启用的具体接口。 |
| 授权机制 | OAuth 授权应当代表真正批准该账号及其门店的所有者或管理员。 | 按租户分别记录权限范围和授权同意，绝不要在不同商家之间共用一套凭证。 |
| 资源类型 | 账号、门店和评论各自对应不同的操作和权限。 | 写入数据之前，先设计好门店标识及其与商家的对应关系。 |
| 请求验证 | 接口使用不当时，一次测试请求也可能影响到真实资源。 | 有预校验功能时优先使用，并把模拟、读取和写入操作分开处理。 |
| 错误处理 | 令牌过期、权限不足和临时性响应错误，含义并不相同。 | 对错误分类处理，采用有限退避重试，并在重试写入前实现幂等机制。 |
| 多租户隔离 | 面向多商家的集成不能只依赖浏览器传来的 ID 作为凭证。 | 在服务器端核实租户、用户、已授权门店和请求的具体操作。 |
| 政策合规 | 获得 API 访问权限不代表可以超出谷歌政策范围使用数据或执行操作。 | 保持操作可追溯、尽量减少数据留存，并在接口变更时及时查阅官方政策和文档。 |
| 使用场景 | 只有存在明确、可重复的系统操作时，接入 API 才有价值，而不是因为接口本身存在。 | 申请权限之前，先写清楚具体的读写流程、负责人、错误处理方式和人工复核环节。 |
| 访问边界 | Google Business Profile API 某项功能是否可用，取决于谷歌当前的访问权限和资格要求。 | 实施时查阅官方文档并确认账号状态，不要承诺人人都能获得的通用访问权限。 |
| 重试机制 | 网络超时可能让客户端无法确认一次写入操作是否已经成功。 | 在操作支持的情况下使用幂等策略，记录服务方返回的标识符，重试前先做核对。 |
| 分页处理 | 对于拥有多个门店的账号，单次响应可能无法包含所有门店、评论或变更记录。 | 设计明确的游标或续传机制，并保存最后一次确认的位置。 |
| 限额与错误 | 配额限制、权限错误和政策变更需要运维人员采取不同的应对措施。 | 对错误分类处理，采用安全等待策略，对重复失败发出告警，并保留人工处理紧急客户问题的渠道。 |
常见问题
Google My Business API 是没有限制的公开 API 吗？
不是。访问、项目、账号、用例、授权和 Business Profile APIs 政策都很重要。
有 OAuth 就能访问所有资料吗？
不能。有效 Token 不代表可以访问所有账号或地点，必须逐项检查授权关系。
集成可以做什么？
取决于可用 API 和权限。每个方法与政策都必须以文档为准。
遇到 429 怎么办？
遵守限额，使用带抖动的退避，限制并发并显示状态，不要无限重试或重复写入。
需要保存全部数据吗？
不需要。减少数据、加密秘密、定义保留期，只保存用例和审计所需内容。
如何避免客户数据混淆？
将 Token、账号、地点、评价和回复绑定到租户，并在服务器读取或写入前强制检查授权。
Repliq 能保证 API 容量吗？
产品页面不能证明配额、访问、容量或供应商行为，这些需要真实环境证据。
下一步
如果用例依赖 API，先验证访问、政策和按账号划分的权限。先实现安全读取和对账，再开启写入。Repliq 应明确显示哪些是草稿、哪些已发布、哪些仍由人控制。
试用 Repliq