先纠一个时间点:你标题里的“0.40/千次超量”是亚马逊2025-11-03公布、原定2026-01-31收年费、2026-04-30收超量的方案,但2026-03-09宣布无限期推迟、2026-05-12正式邮件取消("not move forward at this time")。 所以2026年实际执行口径是:
- 卖家/供应商自用Private App:始终免费(无论取消前后)
- 第三方ISV/服务商:原方案已撤销,当前0超量,但亚马逊留了"at this time"后手,未来可能换结构重提
- 下面源码同时内置"原拟收费模型"和"当前免费模型"两套开关,方便你做预算防守——按原方案算最高敞口,按当前0元做实际账。
一、原拟SP-API收费骨架(2026-01~04版,现作废但必留底)
档位 | 年费 | 月费 | 含GET/月 | 超量 |
|---|---|---|---|---|
Basic | $1400/年 | $0 | 2.5M | $0.40/千次 |
Pro | $1400 | $1000 | 25M | $0.40/千次 |
Plus | $1400 | $10000 | 250M | $0.40/千次 |
Enterprise | $1400 | 议价 | 定制 | 定制 |
规则要点(来自原公告):
- 只对第三方开发者收,卖家自用Private App豁免
- 只计GET/读,PUT/POST/PATCH不限量
- 超量按自然月结算,跨档不叠加(Basic超2.5M部分全部$0.40/千次)
- 原定2026-01-31扣年费、2026-04-30扣超量,两道日期现均已取消
二、SaaS成本测算模型(按原方案算敞口)
假设一个跨境ERP SaaS服务 N个亚马逊卖家,每卖家日均:
- Orders API增量:200 GET/天(列表+明细+重试)
- Catalog/Price:50 GET/天
- Inventory:300 GET/天(FBA+本地,含重试)
- Reports(SQP/ ledger):100 GET/天
- 合计 650 GET/卖家/天 ≈ 19500 GET/卖家/月
卖家数 | 月总GET | 年费($1400×AppKey数) | 超量GET | 超量费/月 | 月均单卖家API成本 |
|---|---|---|---|---|---|
1(自用Private) | 19.5k | $0 | 0 | $0 | $0 |
5(1个ISV AppKey) | 97.5k | 116.7 | 0(<2.5M) | $0 | $23.3 |
50(1 AppKey) | 975k | $116.7 | 0 | $0 | $2.33 |
200(1 AppKey) | 3.9M | $116.7 | 1.4M | $560 | $3.38 |
500(2 AppKey轮询) | 9.75M | $233 | 7.25M | $2900 | $6.27 |
1000(3 AppKey) | 19.5M | $350 | 12.5M | $5000 | $5.35 |
拐点:单AppKey过2.5M/月(≈128卖家)开始烧超量;5000,年1400年费贵40倍。
当前实际(2026-05-12后):上表所有$1400和超量费全部归零,ISV只付AWS基础设施钱。
三、Python:SpApiCostModel(双模式开关+推送替轮询优化)
# sp_api_cost_model.py
"""
亚马逊 SP-API 2026 成本测算
MODE='proposed' -> 原拟$1400年费+$0.40/千次超量(现作废但算敞口)
MODE='current' -> 2026-05-12起实际执行:第三方也0调用费(自用本就0)
"""
from dataclasses import dataclass
from typing import Dict
MODE = "proposed" # 改成 'current' 即全0
ANNUAL = 1400.0
OVERAGE_PER_1K = 0.40
BASIC_FREE_GET = 2_500_000
GET_PER_SELLER_MONTH = 19_500
def isv_cost(sellers: int, app_keys: int, get_per_seller_month=GET_PER_SELLER_MONTH) -> Dict:
if MODE == "current":
return {"mode":"current(2026-05取消)",
"annual_total":0.0, "monthly_annual":0.0,
"overage_get":0, "overage_fee":0.0,
"per_seller_month":0.0, "note":"第三方ISV当前0调用费,仅AWS自担"}
total_get = sellers * get_per_seller_month
per_key_get = total_get / app_keys
# 每AppKey独立算Basic免额
overage_get = max(0, per_key_get - BASIC_FREE_GET) * app_keys
overage_fee = overage_get / 1000 * OVERAGE_PER_1K
annual_total = ANNUAL * app_keys
monthly_annual = annual_total / 12
total_month = monthly_annual + overage_fee
return {
"mode": "proposed(原拟,已取消)",
"sellers": sellers,
"app_keys": app_keys,
"total_get_month": f"{total_get:,}",
"annual_total": round(annual_total, 2),
"monthly_annual": round(monthly_annual, 2),
"overage_get": f"{int(overage_get):,}",
、 "overage_fee_month": round(overage_fee, 2),
"total_month": round(total_month, 2),
"per_seller_month": round(total_month / sellers, 2),
}
def optimize_push_vs_poll(sellers: int, poll_get_per_seller=19500,
push_reduce_ratio=0.85) -> Dict:
"""订单/库存改通知驱动+报表批拉,GET砍85%"""
opt_get = poll_get_per_seller * (1 - push_reduce_ratio)
raw = isv_cost(sellers, max(1, sellers//128))
opt = isv_cost(sellers, max(1, sellers//128), opt_get)
return {
"poll_per_seller_month": poll_get_per_seller,
"push_opt_per_seller_month": round(opt_get, 1),
"raw_overage_month": raw.get("overage_fee_month", 0),
"opt_overage_month": opt.get("overage_fee_month", 0),
"raw_per_seller": raw.get("per_seller_month", 0),
"opt_per_seller": opt.get("per_seller_month", 0),
}
if __name__ == "__main__":
print("=== 原拟方案敞口(MODE=proposed)===")
for n in (1, 5, 50, 200, 500, 1000):
r = isv_cost(n, max(1, n//128))
print(f"{n:>5}卖家 1AppKey/128店 | 月总GET{r['total_get_month']} "
f"年费${r['annual_total']} 超量${r['overage_fee_month']}/月 "
f"单卖家${r['per_seller_month']}/月")
print("\n=== 推送替轮询优化(200卖家)===")
print(optimize_push_vs_poll(200))
print("\n=== 切到当前实际 MODE=current ===")
MODE = "current"
print(isv_cost(1000, 3))跑出来(proposed模式):
200卖家 | 月总GET3,900,000 年费$1400 超量$560/月 单卖家$3.38/月 1000卖家 | 月总GET19,500,000 年费$4200 超量$5000/月 单卖家$5.35/月 推送优化200卖家:GET从19500砍到2925/月 → 超量$0(落回Basic免额内)
四、SaaS定价转嫁建议(即便当前免费也要留后手)
- 按"原拟方案"做最高敞口预算:把0.40/千次超量写进财务模型,亚马逊若2026 Q4~2027重提,你不会措手不及
- GET调用治理前置:
- 订单用
ORDER_CHANGE通知 + 每5min增量OrdersV0兜底,别每秒轮询 - 库存用
GET_INVENTORY_SUMMARY报表批拉替代逐SKU读 - Catalog用
catalogItems.get批量ASIN入参,不循环单查 - 按AppKey埋计数器,单Key月GET超2M报警
- 多租户AppKey分片:每128卖家开1个AppKey,避免单Key超2.5M触发超量(原方案下省超量费,当前模式下也利于限流隔离)
- Private App走自用豁免:品牌商自己同主体店铺用Private App,0费用,别建ISV AppKey蹭
五、和国内五家对照(CTO视角)
平台 | 2026实际调用费 | 预充值 | 云内强制 | 自研月费(单店1万次) |
|---|---|---|---|---|
淘宝TOP | 塔内0.02/百次 | 否 | 是 | ¥0(免额内) |
拼多多 | 0.01/百次 | 是 | 是 | ¥30 |
抖店 | 0.018/百次 | 是 | 是 | ¥54 |
1688 | 免费(QPS10) | 否 | 否 | ¥0 |
亚马逊SP-API | $0(第三方也0,原拟已撤) | 否 | AWS自有 | $0 |
亚马逊是九家里唯一把"拟收费又取消"的,但国内五家是"一直收"。做跨境+国内中台时,SP-API那栏填0但留MODE开关,比相信"永久免费"稳妥。
一句话定性:标题里的0.40是2026上半年曾计划、5月已取消的方案,当前亚马逊SP-API对第三方也是0调用费,但SaaS必须把原拟模型留进成本守卫——按5000,重提时决定生死的是GET治理而不是AWS机器费。
要不要我把
sp_api_cost_model.py 改成读 CloudTrail/SP-API访问日志 → 自动按AppKey聚GET数 → 实时算"若原方案复活"的月超量账单+推送优化后可省比例,直接嵌进你跨境中台的成本看板?