短链接服务 API 横评：2026 年开发者到底能拿到什么

每一家短链接服务卖的都是同一段演示：粘贴一个长 URL，得到一个短的。它们之间的差别要到三周之后才显形——那时一个队列工作进程每小时创建一万条链接，一个 Webhook 处理器正在悄无声息地丢掉重试，还有人在问上个月的点击数据为什么没法和 CRM 对上。这份对比讲的是那个阶段，而不是那段演示。

下面要讲的是：决定一套 API 能否扛住生产环境的那几条维度，这个品类里的主要厂商在每一条上各自实际提供了什么，以及针对 LinkProfit API 的可运行示例。竞品的行为在这里用文字描述，而不是用编造的代码示例：请求的形状会变，而一段已经跑不通的复制代码，比一句解释这个端点做什么的话更糟糕。

对某些买家来说，API 就是产品本身

短链接服务的客户分两类。一类登录控制台，手工创建链接，然后看图表。另一类根本不打开控制台：链接由他们自己的软件、替他们自己的用户创建，点击数据流进他们自己的数仓。对第二类客户来说，控制台是调试工具，API 才是产品的全部。

这道分野解释了这个品类里绝大多数的失望，也正因如此，把短链接能力嵌入 SaaS 产品和采购一件市场工具，本来就是两笔不同的买卖。为第一类买家做优化的厂商，会把 API 当成定价页上的一个勾选项：它存在，文档很薄，被锁在更高的档位后面，而且只覆盖链接创建，不覆盖域名、数据分析和 Webhook。如果你要把短链接能力嵌进一款产品，这道缺口就是「按时上线」和「推倒重来」之间的差别。

真正重要的那几条维度

认证与密钥作用域

起步线是一把 bearer 令牌。真正拉开各家实现差距的，是一把泄露的令牌能干什么。一把覆盖整个账户、能删掉每一条链接的密钥就是一份负债，尤其当你的集成其实只需要创建链接的时候。要找的是：作用域限定在工作区而不是账户上的密钥；权限挂在密钥本身、而不是挂在创建它的那个人身上；以哈希形式存储、创建时只展示一次；以及可以各自独立轮换——这样你就能给每个服务发一把密钥，吊销其中一把也不至于造成停摆。

速率限制，以及撞到上限时的行为

有两个数字要紧，而它们很少被同时公布：可持续的限额，以及越线之后会发生什么。一套行为端正的 API 会返回 429，告诉你什么时候重试，并在每个响应上暴露剩余额度，于是客户端能在开始失败之前自行降速。一套在高压下返回笼统 500、或者悄悄丢掉写入的 API，则逼着你围绕猜测去搭一个过于保守的限流器。

时间窗的形状和数量级同样要紧。平均吞吐相同的情况下，一个按秒设定的上限和一个按分钟滑动的窗口，面对突发型负载的表现完全不同——而多数集成产生的恰恰是突发型负载：一场营销活动发布，九十秒内创建五千条链接，剩下一整天队列都闲着。

批量操作

一次一个 HTTP 请求地创建链接，在几百条的量级上没问题，到几十万条就变成折磨。一个接收整批、并逐条返回结果的批量端点——包括把部分失败连同出错条目的下标一起报出来——能把一个通宵的任务压缩成几分钟。要核对的细节是失败语义：一个无效 URL 会不会导致整批被拒，以及重试一批已经部分生效的数据会不会产生重复。

通过 API 拿到数据分析

几乎每一家厂商都会在控制台里展示点击图表。能让你按需要的粒度用程序把同样的数字拉出来的，就少得多了，而按套餐设定的限制恰恰藏在这里。要问三样东西：聚合汇总、粒度可选的时间序列，以及按国家、城市、设备、浏览器、来源和营销活动参数等维度的拆分。然后再问保留期、导出条数上限，以及计入你套餐额度的事件是不是 API 会返回的同一批事件。这背后的度量问题，尤其是机器人过滤和独立访客计数，在我们的链接点击跟踪指南里有专门讲解。

Rebrandly 是说明这件事为什么要紧的最清晰例子。它的跳转不限量，但数据分析本身被当作互动数据计量，截至 2026 年 8 月，各档位分别是每月 100、10,000、25,000 和 150,000 个事件。一条照常跳转、却停止上报的链接，是一种具体的故障形态，选型之前就该把它算进成本里。

Webhook 与投递保证

靠轮询去发现状态变化，正是集成变慢变贵的方式。Webhook 取代了它，而它的质量归结为四条属性：哪些事件会触发、载荷是否签名、重试计划长什么样，以及重试耗尽之后会怎样。签名校验应当针对原始请求体，并带上时间戳以防重放。重试应当摊在几个小时而不是几分钟里，这样一个发布窗口就不会让你丢掉事件。而且当某个端点被标记为失败时，厂商应当告诉你，而不是悄悄把事件丢掉。

SDK、规范与文档

一个官方 SDK 能省下一天的工作量；一份机器可读的 OpenAPI 规范，则能在 SDK 没有覆盖的任何语言里省下同样这一天，并且随着 API 演进一直省下去。截至 2026 年 8 月，Short.io 提供四个 SDK，是这个品类里官方覆盖面最广的一家。而公开发布的规范是更经久的资产，因为它能生成客户端、mock 和契约测试。

错误、分页与版本策略

三条并不光鲜、却决定维护成本的属性。错误应当机器可读，带一个与人读消息分开的稳定错误码，这样你的重试逻辑就按错误码分支，而不是靠字符串匹配。分页应当基于游标；在一张持续有写入的表上做偏移分页，注定会漏行也会重复行。版本应当明确写在路径里，一旦发布就冻结，破坏性变更放到后继版本里发布。

各家厂商各自提供了什么

| 厂商 | API 可用范围 | 公布的速率限制 | 官方 SDK | 值得注意的限制 | | --- | --- | --- | --- | --- | | Short.io | 所有套餐，含免费档 | 每秒 50 次请求，额外容量按包出售 | 四个 | 没有白标控制台，多团队仅限 Enterprise | | Dub | 核心产品，代码库开源 | 未以标称数字公布 | 有 | 合作伙伴白标位于 300 USD 档位 | | Rebrandly | 付费档位，功能按套餐分层 | 未以标称数字公布 | 有 | 数据分析按互动事件计量 | | Replug | 仅 Agency 套餐，每月 99 USD | 未公布 | 无 | 无法在更低档位上评估 API | | Shlink，自建部署 | 完整，开源 | 由你自行配置 | 社区维护 | 单租户假设，没有计费 | | LinkProfit | Growth 套餐及以上 | 每把工作区密钥每分钟 600 次请求 | 由规范生成的客户端 | 第一版使用共享 API 主机名 |

以上所有套餐与价格信息，均以 2026 年 8 月为准。

Short.io：走量的标尺

Short.io 是这个品类里在价格和吞吐上最激进的一家。它的 API 每个套餐都能用，公布的限制无论档位一律是每秒 50 次请求，额外容量按每秒 50 次请求一包出售，每包每月 50 USD。它提供四个 SDK 和一个像样的开发者文档站，自定义域名连同自动签发的证书从免费档起就已包含。

它的限制在产品的别处，而不在 API 上：它所谓的白标指的是链接上的品牌，而不是一个可换品牌的控制台；多团队支持被圈在 Enterprise 档位里；再营销 pixel 也只覆盖两个平台。如果你需要这些东西，请看我们的 Short.io 替代方案对比。

Dub：API 优先的参照系

Dub 是这个品类在设计和开发者体验上的标杆，有一个开源的内核，产品也是按 API 优先而不是控制台优先建起来的。如果你想找一个「什么叫做得好」的样板，在动手写自己的集成需求之前，先去读一遍他们的文档。

有两点值得澄清，因为这套命名很容易让人误会。Dub Partners 是提供给 Dub 自家客户的联盟计划基础设施，而不是转售 Dub 本身的途径；截至 2026 年 8 月，它的白标化位于每月 300 USD 的 Advanced 档位。Dub 自家的联盟方案是一年内按成交额支付 30%，那是推荐分成安排，而不是分销模式。

Rebrandly 与 Replug：把 API 当作升单手段

两家都把开发者访问权锁在更高档位后面，只是方式不同。截至 2026 年 8 月，Replug 的 API 只在每月 99 USD、年付 79 USD 的 Agency 套餐上提供，这意味着你没法用低成本评估这套集成。Rebrandly 的分层是一项功能一道门，而不是一堵墙：deep link 只出现在 Growth 档位，再营销 pixel 从 Professional 起提供，而上文说的互动数据上限，无论哪个档位都作用在数据分析上。

两种做法都不算稀奇，只要你本来就在门槛之上，也都行得通。对选型来说，要点在于预算上的诚实：你为了 API 而必须选的那个档位，才是你实际要买的档位，而不是你一开始看的那张对比表上的那个。

自建部署与开源

如果你的需求是一个不涉及计费、只有一个租户的内部短链接工具，Shlink 是最强的选择：MIT 许可证，PHP 编写，货真价实的 API 优先，客户端生态也成熟。等你试着拿它去服务别人，它的那些预设就会显形。slug 在整个实例范围内全局唯一，而不是按域名划定；API 密钥的角色机制离真正的租户隔离差得很远；QR 生成功能在第 5 版被移除。Kutt 通过一个定制目录支持换品牌，但节奏已经明显放缓，2026 年全年只有 16 次提交，也没有团队、Webhook 和多租户。YOURLS 从设计上就只支持一个管理员和一个域名。

LinkProfit

我们的设计瞄准的是开头说的第二类买家。密钥按工作区或按合作伙伴签发，带有明确的作用域，只展示一次，并以 SHA-256 哈希形式存储。默认限制是工作区密钥每分钟 600 次请求，合作伙伴密钥 1,200 次，以滑动窗口实施，每个响应都带 X-RateLimit-Limit、X-RateLimit-Remaining 和 X-RateLimit-Reset，返回 429 时还会带上 Retry-After。批量创建每次调用最多接收 100 条链接。数据分析是一等公民，而不是控制台专属：汇总、时间序列、维度拆分，以及最多 100,000 行的流式 CSV 导出。Webhook 带签名，并在大约十二小时内重试五次。规范由校验请求所用的同一批 schema 生成，因此文档不可能与实现脱节。

API 访问权从 Growth 套餐开始提供，这也正是解锁自定义控制台域名的那个档位；完整拆解在定价页面上。第一版里那条如实承认的限制：API 由一个共享主机名提供，因此白标合作伙伴在给客户的文档里把它写成自家的 API，但它并不住在自己的域名上。这是路线图上的一项，而不是一件被藏起来的事。

对接 LinkProfit API 实战

创建一条链接

curl -X POST https://api.linkprofit.com/v1/links \
  -H "Authorization: Bearer lp_live_xxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/spring-collection",
    "slug": "spring",
    "domain_id": "dom_7Kq2f9",
    "expires_at": "2026-10-01T00:00:00Z"
  }'

批量写入

批量端点每次调用最多接收 100 条链接，并逐条返回结果，因此部分失败会指出出问题的那一条，而不是把整批拒掉。

const response = await fetch('https://api.linkprofit.com/v1/links/bulk', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.LINKPROFIT_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    links: batch.map((row) => ({ url: row.destination, slug: row.code, domain_id: domainId })),
  }),
});

if (response.status === 429) {
  const waitSeconds = Number(response.headers.get('retry-after') ?? '1');
  await new Promise((resolve) => setTimeout(resolve, waitSeconds * 1000));
}

把数据分析读回来

拆分接口接收一个维度参数，这让接口面保持小而可预期，而不是每张图表都加一个端点。

curl -G https://api.linkprofit.com/v1/analytics/breakdown \
  -H "Authorization: Bearer lp_live_xxxxxxxxxxxxxxxx" \
  -d dimension=city \
  -d date_from=2026-07-01 \
  -d date_to=2026-07-31

可用的维度覆盖国家、城市、设备、浏览器、操作系统、来源，以及三个主要的营销活动参数，足以在你自己的报表里复现控制台上的数字。

校验一个 Webhook

事件会带上 X-LinkProfit-Signature，格式为 t=timestamp,v1=hex。被签名的载荷是时间戳、一个点，再加上原始请求体，因此校验必须发生在任何可能重新序列化它的 JSON 解析之前。

import { createHmac, timingSafeEqual } from 'node:crypto';

export function isValidSignature(rawBody, header, secret) {
  const fields = new Map(header.split(',').map((pair) => pair.split('=')));
  const timestamp = Number(fields.get('t'));
  // Reject anything outside a five minute window to limit replay.
  if (!Number.isFinite(timestamp) || Math.abs(Date.now() / 1000 - timestamp) > 300) return false;

  const expected = createHmac('sha256', secret).update(`${timestamp}.${rawBody}`).digest('hex');
  const received = Buffer.from(fields.get('v1') ?? '', 'hex');
  const computed = Buffer.from(expected, 'hex');
  return received.length === computed.length && timingSafeEqual(received, computed);
}

投递失败会在一分钟、五分钟、三十分钟、两小时和十二小时之后各重试一次。最后一次尝试之后，该端点会被标记为失败并给账户所有者发邮件，于是一个坏掉的处理器以通知的形式浮出水面，而不是变成一个月后才被发现的数据缺口。

用一个下午评估一套 API

1. 在包含 API 访问权的最便宜套餐上创建一把密钥，并记下这个套餐是不是你本来也会买的那个。
2. 创建、读取、更新并删除一条链接，检查响应里是否带有速率限制头部。
3. 故意超出限额，确认你拿到的是带重试提示的 429，而不是一个笼统的失败。
4. 发一个包含一条无效 URL 的批量请求，看看部分失败是怎么上报的。
5. 拉一份上个月按城市的拆分，把总数和控制台上的对一遍。
6. 用一个能抓取请求的端点注册 Webhook，触发一次事件，校验签名，然后把端点下线，观察它的重试计划。
7. 索取 OpenAPI 文档，并用它生成一个客户端。
8. 读一遍版本策略，以及最近十二个月的更新日志。

第三、第四和第六步是多数选型会跳过的，而它们恰恰是能预测这套集成在凌晨两点表现如何的那几步。

这个品类里有一个货真价实的参考实现 Dub，有一个货真价实的走量选项 Short.io，还有一长串把 API 当作升单手段而非设计目标的产品。我们自己的做法——带作用域的密钥、公开的限额配上诚实的响应头部、把数据分析和域名做成一等资源，以及由校验 schema 生成的规范——记录在 API 功能页上，快速上手、分页、错误码和 Webhook 指南则在文档里。