否则你就得自己把这些都做出来
跳转服务看着简单，直到它不再简单。它必须在全球范围内以个位数毫秒响应，在营销活动带来的流量高峰下扛住而不在热路径上读一次冷数据库，还要缓存「未命中」的结果，免得爬虫盯着一个已失效的 slug 就让你多查一千次，更不能让后端一次短暂的故障变成永久失效的链接。
为客户域名签发证书，则是会悄无声息吃掉一个季度的那部分工作。截至 2026 年 8 月，市面上每一款商用的自托管短链接程序都没有解决客户主机名的 SSL 自动签发——这是整个问题中最难的一块，牵涉到所有权验证、签发速率限制、续期委托，以及一套你的客服团队能讲清楚的状态模型。
再往后是数据分析：每次点击一条事件、地域信息、设备与来源解析、不保存身份标识的独立访客统计、保留期设置，还有在一亿行数据量下依然要快的查询。这些没有一项是你的产品，却每一项都是要长期背着的维护负担。
具体怎么集成
为每位客户建一个工作区，签发一个限定范围的 API 密钥，然后在你的后端调用 REST API。创建链接就是一次 POST，带上目标地址和可选的 slug；一次批量调用最多可创建一百条链接。数据分析返回的是汇总、时间序列、按任意维度的拆分以及流式 CSV 导出，因此你可以把统计直接渲染在自己的界面里，而不是把用户引到别人的控制台去。
客户域名同样是 API 对象。POST 一个主机名，取回它所需的 DNS 记录，再用你自己的文案把它们展示在你自己的接入流程里。订阅域名生命周期的 Webhook，证书一旦生效你的界面就会立刻更新，而不必定时轮询状态端点。
所有接口都由一份 OpenAPI 规范描述，而这份规范正是从 API 实际用于校验的同一套 schema 生成的，因此客户端代码生成可靠，接口文档也不可能与实现脱节。第一版已经冻结：只做增量式改动，破坏性变更一律只出现在新的版本路径上。
- 按工作区限定范围的 Bearer 密钥，每个密钥都有自己的权限清单
- 默认每分钟 600 次请求，每个响应都带有速率限制相关的头部
- 游标分页，在不断有新记录写入时依然稳定
- 所有接口统一的错误结构：错误码、错误信息和文档链接
- Webhook 载荷带签名，端点被判定为失效前会重试五次
面向客户的两种封装方式
隐形集成把一切都留在你的产品里：用户看不到任何第二个品牌，只是在你的界面里拿到短链接和点击图表，数据全部来自 API。这适合那些把链接当作一项功能的产品——排期工具、CRM、邮件工具、电商平台、活动软件。
委托式集成则相反，把完整的控制台直接交给重度用户，跑在你的主机名上、用你的配色、按你设定的套餐和价格计费。它不需要你额外开发，却给了你一档本来只能停留在路线图上的增值套餐；两种模式还可以并行：基础链接放在你的界面里，愿意为此付费的客户则拿到完整的工作台。
成本模型与运维契合度
计费跟着用量走，而不是跟着人头走：你的平台套餐规定了域名数、工作区数和每月跟踪点击量；如果你就链接功能向客户收费，平台按这部分收入抽取一定比例，而不是按工作区收费。从来不打开这项功能的客户，不会给你带来任何成本。
在运维上，跳转的可用性和证书续期不再属于你的值班范围。你的工程师继续负责真正让产品与众不同的部分，而那些只有出故障时才显得与众不同的部分，则交给别人的告警电话。
常见问题
我的每一位客户都能用自己的域名吗？
可以。域名以工作区为范围，通过 API 接入，所以你完全可以在产品里推出一档「自带域名」的套餐。所有权验证、证书签发和续期委托都由我们处理，你只需要在接入流程里把 DNS 记录展示出来。
跳转有多快？
链接是在 edge 上从键值缓存里解析的，而不是查数据库，因此跳转会在离访客最近的位置以个位数毫秒完成。通过 API 做出的改动一秒之内就会同步到 edge——当你的用户期待编辑立即生效时，这一点很关键。
超出 API 速率限制会怎样？
你会收到一个 429 响应，并带有 Retry-After 头部；每个响应里都包含限额、剩余次数和重置时间，客户端可以据此自行控制节奏。批量端点的存在，正是为了让导入数千条链接不必一直顶着速率限制跑。