在法国用 La Poste 的 Colissimo 批量查件，别一上来就硬爬

上周帮朋友的小店处理一批售后：2024 年 11 月发出的 Colissimo 包裹，大概 340 个单号，混着 Colissimo domicile 和 point relais。需求很简单，把「已签收 / 投递中 / 退回」分出来，好决定哪些要主动联系客户。

第一版我图省事，直接拿单号拼 URL 去抓 Colissimo 的公开查件页。结果跑二十几个就开始返回 429，换 UA 也没用，而且页面是前端渲染的，抓到的是壳。

后来改成走它家给商家的 tracking 接口。要点是先在 La Poste 的 developer 门户申请一个 API key，注意它区分 sandbox 和 production，key 不能混用。请求体里单号要成批传，但一批别超过 50 个，我试过 100 个会直接 400：

curl -s -X POST 'https://api.laposte.fr/suivi/v2/idships' \
  -H "X-Okapi-Key: $LAPOSTE_KEY" \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{"idships":["6A12345678901","6A12345678902"]}'

返回里每条有 eventCode 和 isFinal。判断签收别看文案，看 eventCode，比如 DR2 是妥投，DI1 是投递中；文案随语言变，代码相对稳。脚本里做了两件事：每批之间 sleep 1 秒，失败的单号进重试队列，最多 3 次，超过就落盘人工看。340 个单号跑完不到 4 分钟。

为什么不用公开页：公开页没有稳定契约，反爬策略随时变，而且你没法区分「单号不存在」和「被限流」。商家接口有明确的 429 和 404，重试逻辑才写得干净。代价是需要 key、有配额，且不同产品（Colissimo、Chronopost）走的路径不完全一样，我这次只验证了 Colissimo。

会失效的地方：单号格式要先清空格和前缀，法国这边常见带 6A 开头，别自己截；point relais 的包裹在「到达取件点」和「客户取走」之间可能长时间没有新事件，别把它当异常；另外 API 返回的事件时间是带时区的，我一开始按 UTC 存，和店里对账差了一小时。

现在还剩一个没想清楚的问题：退回件（eventCode 以 RE 开头的那类）到底该以「首次扫描到退回」还是「最终入仓」作为触发售后的时间点，你们实际怎么定的？

comment：补一句：sandbox 的 key 拿去打生产会返回 401 而不是报错说 key 不对，我当时在这上面浪费了半小时。

promo：如果你也在法国做小电商或者代购，手里攒着一堆 Colissimo 单号，建议先把「查件」和「通知客户」拆成两步：查件只负责把状态落成结构化数据，通知另外跑。这样接口限流、单号格式错误、时区这些坑都只影响前半段，不会把客户消息也带崩。我这次 340 个单号的经验是，批量接口比爬公开页省心，但前提是你愿意接受 key 和配额这套约束；如果只是偶尔查十几个，手动查反而更快。