Doing what the Shopify API can't — safely 安全地做 Shopify API 做不到的事
A browser-automation (RPA) solution that retroactively links historical customer orders to B2B Company Locations in Shopify Admin — the one workflow Shopify's API simply doesn't expose. 一套浏览器自动化(RPA)方案,把历史客户订单追溯关联到 Shopify 后台的 B2B 公司地点——而这恰恰是 Shopify API 根本不提供的那个操作。
The problem问题
In Shopify B2B, customers often place orders before their account is linked to a Company Location. Those orders stay orphaned — no corporate pricing, missing from the company's purchase history, no unified invoicing. And there can be hundreds of them. 在 Shopify B2B 场景里,客户常常在账户被关联到"公司地点"之前就已经下过单。这些订单成了孤儿——享受不到企业价、不出现在公司采购历史里、无法统一开票。而这样的订单可能有成百上千笔。
The constraint约束
Here's the catch: Shopify's Admin API (both GraphQL and REST) has no endpoint to retroactively associate existing orders with a B2B company. The only supported path is a precise sequence of clicks inside the Admin UI — unlink the customer, save, re-link, and tick a "add the customer's orders to this location" checkbox in a confirmation dialog. Impossible to script through the API; painfully slow by hand. 难点在于:Shopify 的 Admin API(GraphQL 和 REST 都是)没有任何接口能把已存在的订单追溯关联到 B2B 公司。官方唯一支持的路径,是在后台界面里走一套精确的点击流程——解除客户关联、保存、重新关联、并在确认弹窗里勾选"把该客户的订单加入此地点"。这套流程 API 脚本化不了,纯手工又慢得让人崩溃。
The solution: RPA that mimics the exact UI workflow方案:精确复刻 UI 流程的 RPA
A Playwright engine drives the Admin UI through the exact 5-step wizard, triggered by a simple API call carrying a company ID and customer ID. It's built to survive the things that break naive automation: 一个 Playwright 引擎驱动后台界面,走完精确的 5 步向导,由一个携带公司 ID 和客户 ID 的简单 API 调用触发。它被设计成能扛住那些让粗糙脚本崩溃的情况:
- Automated 2FA — without ever holding the client's password long-term. When Shopify demands a login, the script generates the current TOTP code from a secret seed (pyotp), so multi-factor auth never stalls an unattended run. 自动过 2FA——且无需长期持有客户密码。当 Shopify 要求登录时,脚本用密钥种子(pyotp)现算当前的 TOTP 验证码,让多因素认证永远不会卡住无人值守的运行。
- Session persistence. After one successful login the browser state is serialized to JSON and reused, so repeated logins don't trip Shopify's rate limiters and CAPTCHAs. 会话持久化。首次登录成功后,浏览器状态序列化为 JSON 复用,避免反复登录触发 Shopify 的限流和验证码。
- Anti-breakage selectors. Buttons are found by ARIA role and label text, not by fragile CSS class names — so a Shopify UI redeploy doesn't silently break the script. 抗失效选择器。按钮通过 ARIA 角色和标签文本定位,而不是脆弱的 CSS 类名——这样 Shopify 一次界面改版不会悄无声息地弄坏脚本。
- Cloud-ready. Runs headless on Browserless over a secure WebSocket, so there's no Chrome maintenance to babysit. 云端就绪。通过安全 WebSocket 在 Browserless 上无头运行,不用伺候本地 Chrome 的维护。
The trust angle: no password sharing信任要点:无需共享密码
Handing an automation vendor your store password and 2FA seed is a real security worry. This design minimizes that: the client can rotate to a one-click cookie-refresh flow, so I never need standing access to credentials. Solving the client's security anxiety is part of the deliverable — not an afterthought. 把店铺密码和 2FA 种子交给一个自动化外包,是实实在在的安全顾虑。这个设计把风险降到最低:客户可以改用一键 Cookie 刷新流程,我无需长期持有任何凭据。解决客户的安全焦虑,是交付的一部分——而不是事后才想起的补丁。
Proof证明
Verified in a sandbox before any production run. Delivered with a technical design & verification document: the full 5-step UI sequence, a sequence diagram of the login/2FA/retry flow, the anti-breakage selector strategy, and a sandbox verification report confirming the end-to-end association succeeds and the success toast is detected. The mechanics are proven before touching a live store. 在任何生产运行之前,先在沙箱中验证。随附技术设计与验证文档:完整的 5 步 UI 流程、登录/2FA/重试流程的时序图、抗失效选择器策略,以及一份确认端到端关联成功、成功提示被正确捕捉的沙箱验证报告。机制在碰真实店铺之前就已被证明可行。
Where else this applies还能用在哪
Any SaaS admin task the vendor's API refuses to expose: bulk back-office edits, cross-platform syncs (Amazon, HubSpot, POS systems), migrations that only exist as a manual wizard. If your team is clicking the same sequence hundreds of times, it can be a safe, unattended script. 任何 SaaS 后台里、厂商 API 就是不开放的操作:批量后台编辑、跨平台同步(Amazon、HubSpot、POS 系统)、只以手工向导形式存在的数据迁移。如果你的团队在把同一套点击重复几百遍,它就能变成一个安全、无人值守的脚本。
← All case studies← 全部案例