remove.bg API 迁移：实际会变什么

remove.bg 的 API 将于 2026 年 12 月 1 日迁往 Leonardo.Ai。本文给出逐字段差异、三个生产坑，以及我们实测的价格与延迟。

2026年9月21日

BackGone Team

如果你在调用 api.remove.bg，你有一个截止日期：2026 年 12 月 1 日。remove.bg 自己的 API 页现在写得很直白——"Starting December 1, 2026, background removal moves to Leonardo."——并把文档链接指向 Leonardo 的迁移指南，链接带着 utm_source=RBG_website。Leonardo.Ai 隶属 Canva（Canva 官方新闻稿在 2024 年欢迎它加入），而 Canva 自己的公开 API 根本没有抠图接口：我们翻了它公开的 Connect API 规范——52 个端点——命中数为 0。

所以问题不是"要不要迁移"，而是"迁到哪、哪些地方会坏"。下面是我们在自己动手做这件事时整理的逐字段差异、三个只在生产里才会暴露的坑，以及我们在自己的 API 上实测出来的数字——不是抄谁的宣传页。

remove.bg 到底把你送到哪里

这不是传闻。remove.bg 的 API 页上挂着 "Leonardo API Migration" 链接，文档链接带 utm_source=RBG_website&utm_medium=removebg——这是官方的交棒，不是建议。

有意思的是这条路上没有谁：Canva 的公开 API。Canva 拥有目的地，但开发者真正能调的 Connect API 里没有任何抠图端点。如果你的集成需要一个 API，remove.bg 给出的唯一去处就是 Leonardo。

逐字段对照

Leonardo 自己发布了一份对比，而且相当坦率。下面是它对迁移真正要紧的部分，加上我们补的"要注意什么"：

你现在有的（remove.bg）	会变成什么（Leonardo）	要注意什么
`POST https://api.remove.bg/v1.0/removebg`	`POST https://cloud.leonardo.ai/api/rest/v2/generationssync`	换主机、换路径版本
`X-Api-Key: <key>`	`Authorization: Bearer <LEONARDO_API_KEY>`	鉴权头不同——密钥存储与网关规则都要改
`multipart/form-data or JSON`	`JSON only (application/json)`	表单上传不再可用
`image_file / image_url / image_file_b64`	`one image object inside parameters.guidances.image_reference`	图片引用下沉两层
`Implicit model`	`explicit "model": "remove-bg"`	改起来便宜，忘起来也容易
`Raw image bytes by default (JSON optional)`	`always JSON: results[0].url, or dataB64 when you ask for base64`	拿到图之前要再取一次或解码一次
`Nothing kept`	`kept in your Leonardo library unless ephemeral: true`	这是一个可能牵涉隐私政策的存储决定
`png, jpg, webp, zip, auto`	`png, jpg, webp (no zip, no auto)`	批量打 zip 与 format=auto 需要重写
`X-Credits-Charged header`	`cost object in the response body`	成本统计要换个地方读

POST https://api.remove.bg/v1.0/removebg

会变成什么（Leonardo）: POST https://cloud.leonardo.ai/api/rest/v2/generationssync
要注意什么: 换主机、换路径版本

X-Api-Key: <key>

会变成什么（Leonardo）: Authorization: Bearer <LEONARDO_API_KEY>
要注意什么: 鉴权头不同——密钥存储与网关规则都要改

multipart/form-data or JSON

会变成什么（Leonardo）: JSON only (application/json)
要注意什么: 表单上传不再可用

image_file / image_url / image_file_b64

会变成什么（Leonardo）: one image object inside parameters.guidances.image_reference
要注意什么: 图片引用下沉两层

Implicit model

会变成什么（Leonardo）: explicit "model": "remove-bg"
要注意什么: 改起来便宜，忘起来也容易

Raw image bytes by default (JSON optional)

会变成什么（Leonardo）: always JSON: results[0].url, or dataB64 when you ask for base64
要注意什么: 拿到图之前要再取一次或解码一次

Nothing kept

会变成什么（Leonardo）: kept in your Leonardo library unless ephemeral: true
要注意什么: 这是一个可能牵涉隐私政策的存储决定

png, jpg, webp, zip, auto

会变成什么（Leonardo）: png, jpg, webp (no zip, no auto)
要注意什么: 批量打 zip 与 format=auto 需要重写

X-Credits-Charged header

会变成什么（Leonardo）: cost object in the response body
要注意什么: 成本统计要换个地方读

如果你想看同一条对照加上我们那一列，我们的 API 文档一直维护着这张表——包括我们更差的那几行。

三个坑

1. 响应不再是一张图

我们读别人的迁移文章时，看到最多的 bug 就是这个：以前直接流出 PNG 的代码，现在收到的是 JSON。你要么去取那个 URL，要么解码 base64——而两者都有体积上限。Leonardo 自己的指南写明：dataB64 仅在像素数据小于约 7.45 MB 时可用，而同步请求本身最长可能等约 27 秒才超时。

# 以前：响应体就是图片
curl -s -X POST https://api.remove.bg/v1.0/removebg \
  -H "X-Api-Key: $REMOVE_BG_KEY" \
  -F image_file=@photo.jpg -o no-bg.png

# 现在：进 JSON、出 JSON，图片要在你这边解码
curl -s -X POST https://cloud.leonardo.ai/api/rest/v2/generationssync \
  -H "authorization: Bearer $LEONARDO_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"remove-bg","public":false,"ephemeral":true,
       "parameters":{"size":"auto","type":"auto","format":"png",
       "guidances":{"image_reference":[{"image":{"id":"https://example.com/photo.jpg","type":"URL"}}]}}}' \
  | jq -r '.results[0].dataB64' | base64 --decode > no-bg.png

2. 结果默认会被存下来

Leonardo 默认把结果留在你的账号素材库里。想要资产历史时这是功能；处理别人的照片时这是责任——"我们从不保存你的图片"和"你的图片会留在供应商的素材库里直到你删除"，在隐私政策里是两句不同的话。ephemeral: true 会改成给一个 30 分钟有效的链接，这才与 remove.bg 的行为（什么都不留）对齐。

3. 价格现在是公开的

remove.bg 的 API 页公布的是速率限制，不是每张单价。Leonardo 公布了：每张 $0.1047，并在每个响应的 cost 对象里返回。

我们自己的充值档是 $10 / 300 张、$29 / 1,000 张、$99 / 4,000 张、$299 / 15,000 张——摊薄 $0.033 到 $0.020 一张。这个对比我们敢站得住，因为两列数字都是收钱的那一方自己公布的。但它不等于完整决策：每张单价的重要性，低于"这套集成是否贴合你的管线"。

没人问的那个问题：大图会怎样

抠图 API 的评测通常只用好看的样本。真正让你丢客户的，是手机或产品棚拍出来的印前大图。下面这一段是大多数对比文章会跳过的，因为它讲的是服务端而不是模型：如果服务要解码你的结果去检查或缩放像素，每个像素就要占 4 字节内存，而 serverless 运行时对内存是硬上限。

我们自己也撞过这面墙，所以我们的 API 契约里写的是一个数字而不是一句承诺：5000 万像素（8000×6250）——与 remove.bg 当年为 JPG/ZIP 结果公布的上限相同。为了做到这一点，我们对 API 与付费调用在超过 600 万像素时不再解码结果：未检测到主体的检查改用输出文件体积做代理，这是启发式方法，我们在文档里如实标注了。阈值以下行为没有任何变化。

实用建议：迁移之前，拿你最差的那张图跑一遍新 API，而不是拿平均水平的图。下面的脚本就是干这个的。

实测延迟

以下是我们自己线上 API 的单次运行结果（21 September 2026，本机上传）——不是平均值；而且耗时由模型主导，所以数字并不是一条干净的曲线：

请把它读成"大图能用，只是等得久一点"，而不是"与 Leonardo 的跑分对比"：我们没有做过受控的并排测试，也不会发布没测过的数字。

五分钟自己验证这一切

别信迁移指南——包括这一篇。三条命令就够了：

# 1. 截止日期，取自 remove.bg 自己的页面
curl -s https://www.remove.bg/api | grep -o 'Starting December 1, 2026[^<]*'

# 2. Canva 的公开 API 确实没有抠图（52 个端点，0 命中）
curl -s https://www.canva.dev/sources/connect/api/latest/api.yml | grep -ci 'remove.background'

# 3. 拿你最差的那张图分别打两个 API：耗时、输出体积、价格
curl -s -o /dev/null -w 'ours: %{time_total}s %{size_download} bytes\n' \
  -X POST https://backgone.com/api/v1/remove \
  -H "Authorization: Bearer $BACKGONE_KEY" -F image_file=@your-worst-photo.jpg

来源与方法

截止日期与目的地——remove.bg 的 API 页及其迁移指南链接，读取于 2026 年 9 月 21 日
归属关系——Canva 官方新闻稿（欢迎 Leonardo.Ai 加入），2024 年
负面发现——Canva 公开的 Connect API 规范（canva.dev），2026 年 9 月 21 日检索：52 个端点，抠图命中 0
Leonardo 的契约——其官方《Migrate from the remove.bg API》指南；$0.1047、只收/只回 JSON、默认存储、格式清单均出自该页
我们的延迟与输出体积——2026 年 9 月 21 日对 backgone.com/api/v1/remove 的单次调用，每种尺寸一次，本机上传；输出体积只记录了最小与最大两档
内存图——字节数是算术（RGBA 每像素 4 字节）；通过/失败边界是生产实测：6MP 与 9MP 返回 200，12MP 在仍会解码的那条路径上返回 Cloudflare 错误 1102

常见问题

2026 年 12 月 1 日之后还能继续调 remove.bg 的 API 吗？ 它自己的页面写着抠图在那天迁往 Leonardo。请按"端点会消失"来规划；不要赌一个没有任何官方文档支持的宽限期。

只有 Leonardo 一个选择吗？ 不是——它是 remove.bg 选择指向的去处。真正值得对比的是两件事：契约（请求形态、响应形态、存储）与每张单价；这两样任何一家正经供应商都会公布。

要改多少代码？ 如果跟着 remove.bg 的指针走：鉴权头、请求体结构、图片引用、响应处理、成本统计，全都要改。如果你保持"表单进、图片出"的形态，改动更少。

需要在意图尺寸吗？ 需要，而且这是这类 API 里被记录得最少的部分。承诺之前先用你最大的真实输入测一遍，并且看清"太大"时它会怎么回应：一个带上实测像素数的明确错误，比一个莫名其妙的 500 有价值得多。

本文由 BackGone 团队撰写，我们运营上面链接的那个抠图 API。文中每个数字都来自我们自己的生产实测，或来自紧挨着它的那份一手文档；凡是只测了一次而非多次的地方，正文都注明了。如果你发现错误，告诉我们，我们会修正并说明改了什么。