リンク短縮APIの比較——2026年に開発者が手にするもの

リンク短縮サービスはどれも同じデモを売っています。長いURLを貼り付けると、短いURLが返ってくる。違いが表に出るのは3週間後です。キューのワーカーが1時間に1万件のリンクを作り、Webhookのハンドラーが再送を黙って取りこぼし、誰かが「先月のクリックデータはなぜCRMと突き合わせられないのか」と尋ねる頃です。本稿が扱うのは、デモではなくその段階です。

以下では、APIが本番の現場に触れて生き残れるかどうかを決める軸を挙げ、この分野の主要なベンダーが各軸で実際に何を提供しているのかを示し、LinkProfitのAPIに対して動く例を載せます。他社の挙動については、作り込んだコード例ではなく文章で説明します。リクエストの形は変わりますし、もう通らないスニペットを写して置いておくくらいなら、そのエンドポイントが何をするのかを説明した一文のほうが役に立つからです。

一部の買い手にとって、APIこそが製品である理由

短縮サービスの顧客には2種類あります。一方はダッシュボードにログインし、手作業でリンクを作り、グラフを読みます。もう一方はダッシュボードをまったく開きません。リンクは自社のソフトウェアが、自社のユーザーに代わって作り、クリックのデータは自社のデータウェアハウスへ流れ込みます。後者にとって、ダッシュボードはデバッグの道具であり、製品そのものはAPIです。

この区別が、この分野で起きる失望のほとんどを説明します。SaaS製品にリンク短縮を組み込むことが、マーケティングツールを買うのとは別の買い物になるのも、そのためです。前者の買い手に合わせて最適化しているベンダーは、APIを価格ページのチェック項目として扱います。存在はする、ドキュメントは薄い、上位の階層に閉じ込められている、そしてリンクの作成は扱うがドメインも分析もWebhookも扱わない、というわけです。製品にリンク短縮を組み込むなら、この差はそのまま、出荷できるか書き直すことになるかの差になります。

本当に効いてくる評価の軸

認証とキーのスコープ

出発点はBearerトークンです。実装の差が出るのは、漏れたトークンに何ができるかという点です。すべてのリンクを削除できるアカウント全体のキーが1本だけ、という構成は負債です。連携の側はリンクを作るだけでよい、という場合はなおさらです。見るべきなのは、アカウントではなくワークスペースに紐づいたスコープを持つキー、キーを作った人ではなくキー自体に付いた権限、作成時に一度だけ表示されハッシュとして保存される仕組み、そして個別のローテーションです。サービスごとにキーを発行し、停止を起こさずに1本だけ失効させられる必要があります。

レート制限と、上限に達したときの挙動

重要な数字は2つあり、その両方が公開されていることはめったにありません。持続できる上限と、それを超えたときに何が起きるかです。行儀のよいAPIは429を返し、いつ再試行すればよいかを伝え、残りの枠をすべての応答に載せます。おかげでクライアントは、失敗し始める前に自分で流量を絞れます。負荷がかかると汎用的な500を返すAPIや、書き込みを黙って捨てるAPIを相手にすると、推測に基づいた保守的なレートリミッターを自前で組む羽目になります。

窓の形は、大きさと同じくらい効いてきます。平均のスループットが同じでも、毎秒の上限と毎分のスライディングウィンドウでは、バースト的な負荷に対する振る舞いがまったく違います。そして大半の連携が生むのは、まさにそのバースト的な負荷です。キャンペーンが公開され、90秒で5,000件のリンクが作られ、その日の残りはキューが空のまま、という形です。

一括処理

HTTPリクエスト1本につきリンク1件という作り方は、数百件なら問題ありませんが、数十万件になると苦痛です。バッチを受け取り、失敗した項目の位置を含めて要素ごとの結果を返す一括エンドポイントがあれば、一晩がかりの処理が数分で終わります。確かめるべき細部は、失敗したときの意味論です。無効なURLが1件混じっただけでバッチ全体が弾かれるのか、そして途中まで適用されたバッチを再試行すると重複が生まれるのか、という点です。

APIから取れる分析

クリックのグラフをダッシュボードに表示するベンダーは、ほぼすべてです。同じ数字を、必要な粒度でプログラムから取得させてくれるところは、ぐっと少なくなります。プランごとの制限が隠れているのも、まさにここです。求めるべきものは3つ。集計のサマリー、粒度を選べる時系列、そして国、都市、デバイス、ブラウザー、参照元、キャンペーンのパラメーターといった次元ごとの内訳です。そのうえで、保持期間、書き出しの件数上限、そしてプランの枠で数えられるイベントとAPIが返すイベントが同じものかどうかを尋ねてください。その下にある計測そのものの論点、とりわけボットの除外とユニーク訪問者の数え方については、クリックの計測のガイドで扱っています。

これが効いてくる理由の最も分かりやすい例がRebrandlyです。リダイレクトは無制限ですが、分析そのものはエンゲージメントデータとして従量の対象になっており、2026年8月時点で各階層は月100、10,000、25,000、150,000イベントに制限されています。リダイレクトは動き続けるのに、レポートだけが止まる——これは固有の壊れ方であり、選ぶ前に見積もりへ織り込んでおくべきものです。

Webhookと配信の保証

状態の変化をポーリングで追いかけるのは、連携が遅く高くつくようになる典型的な経路です。Webhookはそれを置き換えるもので、品質は4つの性質に集約されます。どのイベントが発火するか、ペイロードに署名が付くか、再送のスケジュールはどうなっているか、そして再送を使い切ったあとに何が起きるかです。署名の検証は、リプレイを防ぐタイムスタンプとともに、生のボディに対して行われるべきです。再送は数分ではなく数時間にわたって分散されるべきで、そうであればデプロイのための停止時間がイベントの損失に直結しません。そしてベンダーは、エンドポイントが失敗と判定されたことを、黙ってイベントを捨てるのではなく、こちらに知らせるべきです。

SDK、仕様、ドキュメント

公式のSDKがあれば作業が1日分減ります。機械可読のOpenAPI仕様があれば、SDKが対応していない言語でもその1日分が減り、APIが進化しても減り続けます。2026年8月時点で、Short.ioは4つのSDKを提供しており、この分野で公式の対応範囲が最も広いのは同社です。より長持ちする資産は、公開された仕様のほうです。そこからクライアント、モック、契約テストを生成できるからです。

エラー、ページネーション、バージョン管理

見栄えはしないものの、保守の費用を決めてしまう3つの性質です。エラーは機械可読であるべきで、人間向けの文言とは別に安定したコードを持つべきです。そうすれば再試行のロジックは、文字列の一致ではなくコードで分岐できます。ページネーションはカーソル方式であるべきです。書き込みが入るテーブルに対するオフセット方式のページネーションは、行の取りこぼしと重複を起こします。そしてバージョンはパスに明示され、公開したら凍結され、互換性を壊す変更は後継のバージョンで出されるべきです。

各ベンダーが提供しているもの

| ベンダー | APIの提供範囲 | 公表されたレート制限 | 公式SDK | 注目すべき制約 | | --- | --- | --- | --- | --- | | Short.io | 無料を含む全プラン | 毎秒50リクエスト、追加はブロック単位で販売 | 4つ | ホワイトラベルのダッシュボードなし、チームはEnterpriseのみ | | Dub | 中核の製品、オープンソースのコードベース | 見出しの数字としては非公表 | あり | パートナーのホワイトラベルは月300 USDの階層 | | Rebrandly | 有料の階層、機能はプランごとに制限 | 見出しの数字としては非公表 | あり | 分析はエンゲージメントイベントとして従量制 | | Replug | Agencyプランのみ、月額99 USD | 非公表 | なし | 下位の階層でAPIを評価できない | | Shlink（セルフホスト） | 全機能、オープンソース | 自分で設定する | コミュニティ製 | 単一テナント前提、課金なし | | LinkProfit | Growthプラン以上 | ワークスペースキーごとに毎分600リクエスト | 仕様から生成するクライアント | バージョン1ではAPIのホスト名が共有 |

上記のプランと価格の詳細は、すべて2026年8月時点のものです。

Short.io——物量の基準

Short.ioは、この分野で価格とスループットを攻めている存在です。APIはどのプランでも使え、公表されている上限は階層に関係なく毎秒50リクエスト、追加の容量は毎秒50リクエストのブロック単位で月50 USDで販売されています。SDKは4つ、開発者向けのドキュメントサイトも本格的で、証明書を自動で発行する独自ドメインは無料の階層から含まれます。

制約があるのはAPIではなく、製品の別の場所です。同社がホワイトラベルと呼ぶのはリンクのブランディングであってダッシュボードの差し替えではなく、複数チームへの対応はEnterpriseに限られ、リターゲティングのピクセルは2つのネットワークにしか対応していません。それらが必要なら、当社のShort.ioの代替比較をご覧ください。

Dub——API優先の参照実装

Dubは、この分野におけるデザインと開発者体験の基準です。中核はオープンソースで、ダッシュボードではなくAPIを先に据えて作られています。この領域で良いものがどう見えるのかの手本が欲しいなら、自社の連携要件を書き始める前に、同社のドキュメントを読んでください。

名称が誤解を招くので、2点だけ補足しておきます。Dub Partnersは、Dubの顧客に提供されるアフィリエイトプログラムの基盤であって、Dubそのものを再販する仕組みではありません。そのホワイトラベルは、2026年8月時点で月額300 USDのAdvanced階層に置かれています。また同社自身のアフィリエイト制度は販売額の30パーセントを1年間支払うもので、これはリセラーのモデルではなく紹介の取り決めです。

RebrandlyとReplug——上位プランへの誘導としてのAPI

どちらも開発者向けの機能を上位の階層に置いていますが、その置き方は異なります。ReplugのAPIは、2026年8月時点で月額99 USD、年払いなら月あたり79 USDのAgencyプランでしか使えません。つまり、連携を安く評価することができません。Rebrandlyの出し惜しみは、1枚の壁ではなく機能ごとに引かれています。ディープリンクはGrowth以上にしか現れず、リターゲティングのピクセルはProfessional以上、そして先ほど述べたエンゲージメントデータの上限は、階層に関係なく分析に適用されます。

どちらのやり方も珍しくはなく、しきい値の上に立っているなら実務上は問題ありません。評価にあたって大事なのは、予算について正直であることです。APIのために必要な階層こそが実際に買う階層であって、最初に眺めていた比較表の階層ではありません。

セルフホストとオープンソース

求めているものが、課金もなくテナントも1つだけの社内向け短縮サービスなら、最も有力なのはShlinkです。MITライセンス、PHP、本当の意味でAPIを中心に設計されており、クライアントのエコシステムも成熟しています。その前提が姿を現すのは、他人に提供しようとしたときです。スラッグはドメインごとではなくインスタンス全体で一意であり、APIキーのロールは本物のテナント分離には近づいてすらおらず、QRの生成はバージョン5で削除されました。Kuttはカスタマイズ用のディレクトリ経由でブランドの差し替えに対応しますが、開発の勢いはかなり落ちています。2026年を通じたコミットは16件で、チーム機能もWebhookもマルチテナントもありません。YOURLSは設計からして、管理者1人とドメイン1つです。

LinkProfit

当社の設計は、冒頭で述べた2種類目の買い手に向いています。キーはワークスペースごと、あるいはパートナーごとに発行され、明示的なスコープを持ち、一度だけ表示されてSHA-256のハッシュとして保存されます。既定の上限はワークスペースキーが毎分600リクエスト、パートナーキーは1,200リクエストで、スライディングウィンドウで適用されます。すべての応答にX-RateLimit-Limit、X-RateLimit-Remaining、X-RateLimit-Resetが載り、429にはRetry-Afterが付きます。一括作成は1回の呼び出しで最大100件のリンクを受け付けます。分析はダッシュボード限定ではなく第一級の機能で、サマリー、時系列、次元ごとの内訳、そして100,000行を上限とするストリーミングのCSV書き出しがあります。Webhookには署名が付き、およそ12時間かけて5回再送されます。仕様はリクエストの検証に使うのと同じスキーマから生成されるため、ドキュメントが実装から乖離することはありません。

APIの利用はGrowthプランから始まります。ダッシュボード用の独自ドメインが解放されるのも同じ階層です。詳しい内訳は価格ページにあります。バージョン1における正直な制約はこうです。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"
  }'

書き込みをまとめる

一括エンドポイントは1回の呼び出しで最大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));
}

分析を読み出す

内訳は次元をパラメーターとして受け取ります。グラフごとにエンドポイントを増やすのではなくこの形にすることで、APIの表面積は小さく、予測しやすいままに保たれます。

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

使える次元は、国、都市、デバイス、ブラウザー、オペレーティングシステム、参照元、そして主要な3つのキャンペーンパラメーターをカバーします。ダッシュボードの数字を自社のレポートで再現するには、これで足ります。

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);
}

配信に失敗すると、1分後、5分後、30分後、2時間後、12時間後に再送されます。最後の試行のあと、そのエンドポイントは失敗と判定され、アカウントの所有者にメールが届きます。壊れたハンドラーは、1か月後に見つかる欠損データとしてではなく、通知として表に出るということです。

半日でAPIを評価する

1. APIを使える最も安いプランでキーを作り、そのプランがそもそも自分で買うつもりのものだったかどうかを書き留めます。
2. リンクを1本、作成、取得、更新、削除し、応答にレート制限のヘッダーが載っているかを確認します。
3. 意図的に上限を超え、汎用的な失敗ではなく、再試行の手がかりを伴う429が返ることを確かめます。
4. 無効なURLを1件だけ含む一括リクエストを送り、部分的な失敗がどう報告されるかを見ます。
5. 先月分の都市別の内訳を取得し、合計をダッシュボードと突き合わせます。
6. リクエストを記録するエンドポイントにWebhookを登録し、イベントを発火させ、署名を検証し、そのうえでエンドポイントを停止して再送のスケジュールを観察します。
7. OpenAPIのドキュメントを取得し、そこからクライアントを生成します。
8. バージョン管理の方針と、直近12か月の変更履歴を読みます。

3番、4番、6番は、たいていの評価が飛ばしてしまう手順です。そして、連携が午前2時にどう振る舞うかを予告してくれるのも、この3つです。

この分野には、本物の参照実装としてのDubがあり、物量に耐える本物の選択肢としてのShort.ioがあり、そしてAPIが設計目標ではなく上位プランへの誘導になっている製品のロングテールがあります。当社自身の考え方——スコープを持つキー、正直なヘッダーを伴う公表済みの上限、第一級の資源としての分析とドメイン、そして検証スキーマから生成される仕様——はAPIの機能にまとめてあり、クイックスタート、ページネーション、エラーコード、Webhookのガイドはドキュメントにあります。