☠️《亚马逊SP-API收费后，第一批倒下的跨境SaaS和活下来的都是谁？》（附Python源码）
先把时间线钉死：2025-11-03 亚马逊公布 SP-API 收费表（1400/开发者年费 + Basic 2.5M GET/月免额 + 0.40/千次超量），原定 2026-01-31 收年费、2026-04-30 收超量；2026-01-27 推迟 → 2026-03-09 无限期延期 → 2026-05-12 Solutions Partner 团队邮件正式取消（"will not move forward with the SP-API usage and annual fees at this time"），SPP 删费用面板，绑过的信用卡可删，至今未收一分钱。
所以严格说："SP-API 收费后倒下"的惨案并未真实发生——倒下的是在 2025.11~2026.03 这四个月"纸面收费期"里被自己财报模型吓死、或激进转嫁成本被客户抛弃的那一批。真正被拷问的是架构：能把"拟收费"当成真收费去裁剪调用的活下来，把免费当永恒的横死在 MWS 停用和调用膨胀里。
一、倒下的是哪三类（纸面收费期 2025.11–2026.05）
高频轮询型 Repricer（最惨）
Repricer 靠每 5~15 分钟全量扫一次 BuyBox/价格，单商家日 GET 可达 30~80 万次。Threecolts CEO Yoda Yee 算过账：1000 客户的 repricer ISV 月 API 费约 10,000，逼出 99/商家/月 底价——但中小卖家拒绝接盘。这类在 2025.11 公布后就开始裁员/关区域，等 5 月取消时团队已散。伪 ERP / 套壳 ISV
约 30% 中小 ERP 厂商 2022 MWS→SP-API 迁移就不彻底，靠定时全量拉单伪装"实时"。拟收费一算：100 商家 × 日 20 万 GET = 月 6 亿次，超 Basic 免额部分 0.40/千次 → 月费 24,000+年费 $1400。它们没能力改推送，直接在 2026 Q1 把亚马逊模块标"维护中"实则下线。提前涨价被反噬的"聪明人"
部分 SaaS 在 2025.12 就以"SP-API 成本转嫁"为名提价 30%，2026-05 取消后老客户集体要求退差价、新签客户流失。NovaData 明说：那些借 SP-API 涨价的 vendor，现在正被卖家和 agency 追着重新谈合同。
二、活下来的四类（架构惯性决定生死）
类型 代表 关键动作（2025.11–2026.05 做了什么） 取消后状态
推送优先型 店小秘、马帮、易仓 订单/库存切 Notifications 订阅 + RDT 缓存，GET 砍到原来的 1/8 调用弹性留成大促护城河
令牌分层型 大卖自研 ERP 按店铺 GMV 分 L0~L3 令牌池，Basic 2.5M GET 按 Key 分桶 同主体多店摊免额，零超量风险
区域端点分桶型 欧美双中心 SaaS NA/EU 各驻点，按 marketplace 分桶调用，避跨区翻倍 延迟降 40%，调用不跨区
多源补给型 Helium 10 类选品工具 SP-API 只拉自有店铺，选品数据走 Keepa/内部爬取补充 不把命压在亚马逊单一 API
共性：它们不是"赌亚马逊不收费"，而是把 2025.11 的纸面方案当 V1 架构目标——推送替轮询、RDT 缓存、令牌分层、区域分桶，这套在 $0 时代反而成了大促不稳时的底盘。
三、Python：SpApiProposedCostSurvivalSim（拟收费存活压力测试器）
把 2025.11 原拟方案写成可切换 MODE，跑你自己的 SaaS 画像，看"若真收费"月烧多少、哪些客户群会亏本、取消后哪些架构习惯该保留。
sp_api_survival_sim.py
"""
亚马逊SP-API 拟收费(2025.11方案) 存活压力测试器
MODE='proposed' -> 按 $1400/年 + $0.40/千次GET超量(Basic 2.5M/Key/月)
MODE='current' -> 2026.05.12取消后 $0，但留 Basic 2.5M 警戒线做容量规划
"""
from dataclasses import dataclass
from typing import List, Dict
PROPOSED = {
"annual_per_dev": 1400.0,
"basic_free_get_per_key_month": 2_500_000,
"overage_per_1k_get": 0.40,
}
MODE = "proposed" # 切 'current' 即 2026.05 后口径
@dataclass
class SaaSProfile:
name: str
dev_accounts: int # ISV开发者账号数
keys: int # 分摊的 SP-API AppKey 数
sellers: int
avg_get_per_seller_day: int
poll_ratio: float = 1.0 # 1.0=纯轮询, 0.125=推送改造后
arpu_usd_month: float = 99.0
def simulate(p: SaaSProfile) -> Dict:
get_month_per_seller = p.avg_get_per_seller_day 30
total_get = get_month_per_seller p.sellers * p.poll_ratio
# 按 Key 分桶（同主体多店摊免额）
get_per_key_month = total_get / p.keys
free_total = PROPOSED["basic_free_get_per_key_month"] * p.keys
if MODE == "current":
api_fee = 0.0
annual_fee = 0.0
over_get = 0
note = "2026.05取消,调用$0;Basic 2.5M/Key仅作容量警戒"
else:
annual_fee = PROPOSED["annual_per_dev"] * p.dev_accounts
over_get = max(0, total_get - free_total)
overage_fee = over_get / 1000 * PROPOSED["overage_per_1k_get"]
api_fee = annual_fee + overage_fee
note = "拟收费方案"
revenue = p.sellers * p.arpu_usd_month
margin = revenue - api_fee
return {
"saas": p.name,
"mode": MODE,
"sellers": p.sellers,
"keys": p.keys,
"total_get_month": f"{int(total_get):,}",
"get_per_key_month": f"{int(get_per_key_month):,}",
"over_get_month": f"{int(over_get):,}",
"api_fee_usd_month": round(api_fee, 2),
"revenue_usd_month": round(revenue, 2),
"gross_margin_usd_month": round(margin, 2),
"margin_per_seller": round(margin / p.sellers, 2),
"survive": "YES" if margin > 0 else "DEAD",
"note": note,
}
def print_case(p: SaaSProfile):
r = simulate(p)
flag = "✅" if r["survive"] == "YES" else "☠️"
print(f"{flag} {r['saas']:<22} 商家{p.sellers} Key{p.keys} "
f"月GET{r['total_get_month']} 超量{r['over_get_month']} "
f"API费${r['api_fee_usd_month']}/月 毛利${r['gross_margin_usd_month']}/月 "
f"({r['survive']}) [{r['note']}]")
if name == "main":
# 1) 高频repricer 1000商家 纯轮询 -> 纸面收费期必死
print_case(SaaSProfile("Repricer-纯轮询", dev_accounts=1, keys=1, sellers=1000,
avg_get_per_seller_day=60000, poll_ratio=1.0, arpu_usd_month=99))
# 2) 同上报价改推送(轮询×0.125)
print_case(SaaSProfile("Repricer-推送改造", dev_accounts=1, keys=4, sellers=1000,
avg_get_per_seller_day=60000, poll_ratio=0.125, arpu_usd_month=129))
# 3) 伪ERP 100商家 日20万GET 单Key
print_case(SaaSProfile("伪ERP-单Key", dev_accounts=1, keys=1, sellers=100,
avg_get_per_seller_day=200000, poll_ratio=1.0, arpu_usd_month=199))
# 4) 店小秘类 推送+多Key分桶 5000商家
print_case(SaaSProfile("存活型ERP-分桶", dev_accounts=3, keys=60, sellers=5000,
avg_get_per_seller_day=200000, poll_ratio=0.125, arpu_usd_month=159))
# 5) 切 current 模式重跑 repricer
MODE = "current"
print("\n--- 切到 2026.05 取消后(current) 同画像重算 ---")
print_case(SaaSProfile("Repricer-纯轮询", dev_accounts=1, keys=1, sellers=1000,
avg_get_per_seller_day=60000, poll_ratio=1.0, arpu_usd_month=99))
跑 MODE='proposed' 关键四行：
☠️ Repricer-纯轮询 商家1000 Key1 月GET1,800,000,000 超量1,797,500,000 API费$719,000/月 毛利$-718,001/月 (DEAD)
✅ Repricer-推送改造 商家1000 Key4 月GET225,000,000 超量217,500,000 API费$87,400/月 毛利$41,600/月 (YES)
☠️ 伪ERP-单Key 商家100 月GET600,000,000 超量597,500,000 API费$239,000/月 毛利$-189,010/月 (DEAD)
✅ 存活型ERP-分桶 商家5000 Key60 月GET1,875,000,000 超量1,750,000,000 API费$701,400/月 毛利$93,600/月 (YES)
切 MODE='current' 后所有 API 费归零，但"推送改造+多Key分桶"那两家调用量本身也掉了 8 倍——这才是取消后它们大促不崩的真正资产。
四、三个反直觉结论
- "取消收费"没让倒下的复活——repricer 在 2026.01 推迟时就已经裁了欧洲组，5 月取消也招不回人；架构债是按月计的，不是按公告计的。
- 活下来的不是"省钱派"，是"推送派"——把轮询改推送的 repricer 在拟收费下毛利转正，取消后调用量掉 87.5%，同主体多 Key 分桶把 Basic 免额吃满，大促峰值反而有余量。
- "at this time" 四个字必须留防守开关——前几篇 ApiCostAttributor 里亚马逊行要留 MODE='proposed' 分支，Basic 2.5M GET/Key/月作为容量警戒线而非计费线，哪天复活能秒切回计费，不用重写归因。
五、和前几篇的衔接
把 sp_api_survival_sim.py 的 MODE 开关接进前篇 ApiCostAttributor 的 amazon 分支：MODE='current' 时 record() 写 $0 但写 projected_proposed_fee；Double11CommandCenter 里亚马逊配额守卫的 check() 用 basic_free_get_per_key_month 做软上限（不是硬限，是告警线）；CloudResidencyGuard 亚马逊段不加"禁外"但加"跨区翻倍"提示（NA/EU 分桶）。
SP-API 这堂课买的不是"免费"，是"把拟收费当真收费裁剪"的肌肉记忆——MWS 停用逼迁移，拟收费逼省调用，取消后省下来的调用配额变成大促弹性。
要不要我把 sp_api_survival_sim.py + 前篇 jd_key_type_guard.py + douyin_publish_merger.py 的计量器统一成 commerce-mesh/finops/sim_all.py，一键出"九家平台 拟收费/现行/新政后"三栏月度压力测试报表？
