ソースを読める 短縮サービス。
レイテンシ、エラー率、MTTRを測定。ソースコードを読み解ける短縮リンク基盤。
- REST + gRPC: サービスメッシュが好む方を選択
- すべてのリダイレクト、すべてのAPI呼び出しにOpenTelemetryスパン
- 6つのSDK: TypeScript、Go、Python、Ruby、PHP、.NET
- Apache 2.0セルフホスト、ワンコマンドHelmチャート
curl -X POST https://api.elido.app/v1/links -H "Authorization: Bearer $ELIDO_API_KEY" -H "Idempotency-Key: ci-2026-05-08-build-4419" -d '{ "destination_url": "https://shop.example.com/launch", "slug": "q2-launch", "workspace_id": "ws_8f3c" }'
{ "id": "link_01HQ3X...", "short_url": "https://b.elido.me/q2-launch", "click_tracker": "https://api.elido.app/v1/links/link_01HQ3X/clicks", "expires_at": "2026-08-08T00:00:00Z", "created_at": "2026-05-08T11:24:01Z" }
オブザーバビリティ - 後付けではなく組み込み
すべてのリダイレクトがOpenTelemetryスパンを発行。すべてのスパンがコレクターに送信。
エッジサービスはOTelでエンドツーエンドにインストルメントされています。OTLPコレクターをリダイレクト層に向けると、キャッシュルックアップ、ルール評価、レスポンス、非同期クリックイベントパブリッシュの完全なウォーターフォールが得られます - インストルメンテーションを1行も書かずに。
SDKs
同一の標準呼び出し。6言語。1つの仕様から全て生成。
すべてのSDKは同一のOpenAPI 3.1仕様から生成されます。サーバーに新しいエンドポイントが追加されたら、ジェネレーターを実行してSDKをリリースするだけ。APIから乖離した手動管理クライアントはありません。冪等性キー、指数バックオフによる再試行、型付きエラーレスポンスが6言語全て一貫して提供されます。
- OpenAPI 3.1が唯一の情報源仕様はチェックイン済み。SDKはリリースごとに再生成。
- 型付きエラーレスポンスレート制限、バリデーション、競合 - 全て型付き、文字列キャッチなし。
- 冪等性キーすべての書き込みエンドポイントにヘッダーベースで、再試行時に再利用。
- 組み込み再試行Retry-Afterを各言語で遵守した指数バックオフ。
create-link.ts1import { Elido } from2 "@elido/sdk";34const elido = new Elido({5 apiKey: process.env.ELIDO_API_KEY!,6});78const link = await elido.links.create({9 destinationUrl: dest,10 slug: "q2-launch",11});
create-link.go1import "github.com/elido/sdk-go"23client := elido.NewClient(4 elido.WithAPIKey(key),5)67link, err := client.Links.Create(ctx,8 &elido.CreateLinkRequest{9 DestinationURL: dest,10 Slug: "q2-launch",11 })
create_link.py1from elido import Elido23elido = Elido(4 api_key=os.environ["ELIDO_API_KEY"],5)67link = elido.links.create(8 destination_url=dest,9 slug="q2-launch",10 idempotency_key=build_id,11)
gRPCコントラクト
protobufでも同じインターフェース - サービスメッシュネイティブ向け。
当社のAPIは同一ハンドラーからRESTとgRPCの両方を提供します。プラットフォームがprotoネイティブ（Envoy、Istio、Linkerd、Connect-Go）であれば、JSONレイヤーをスキップできます。.protoファイルは公開されており、bufまたはprotocがサポートする任意の言語でクライアントを生成できます。
1syntax = "proto3";23package elido.api.v1;45option go_package = "github.com/elido/proto/api/v1;apiv1";67service LinkService {8 rpc Create(CreateLinkRequest) returns (Link);9 rpc Resolve(ResolveLinkRequest) returns (ResolveLinkResponse);10 rpc List(ListLinksRequest) returns (ListLinksResponse);11 rpc Delete(DeleteLinkRequest) returns (google.protobuf.Empty);12}1314message CreateLinkRequest {15 string workspace_id = 1;16 string destination_url = 2;17 optional string slug = 3;18 optional google.protobuf.Timestamp expires_at = 4;19 repeated KeyValue tags = 5;20}2122message Link {23 string id = 1;24 string short_url = 2;25 string destination_url = 3;26 google.protobuf.Timestamp created_at = 4;27}
Authenticate with workload identity via SPIFFE/SPIRE or your mesh's built-in mTLS. API keys still work for non-mesh callers.
One implementation in api-core. Connect-Go transcoding means the REST surface is generated, not separately maintained.
ResolveLinkResponse streams click events for hot links - useful for internal dashboards without webhook plumbing.
すぐに使えるもの
- REST + gRPC: サービスメッシュが好む方を選択
- すべてのリダイレクト、すべてのAPI呼び出しにOpenTelemetryスパン
- 6つのSDK: TypeScript、Go、Python、Ruby、PHP、.NET
- Apache 2.0セルフホスト、ワンコマンドHelmチャート
- HMAC-SHA256署名付きウェブフックファイアホース
- すべてのサービスにPrometheus /metricsエンドポイント
Elido APIが提供する真の価値
OpenAPI仕様とBearerトークンは最低限の基準です。以下の機能こそが、午前2時にトラブル対応に追われる短縮サービスと、真に信頼して構築できるサービスを分ける違いです。
44の文書化されたエンドポイントを持つOpenAPI 3.1 - 未公開ルートなし
本番環境のすべてのエンドポイントはOpenAPI 3.1仕様に記載されています。シャドウルートや、ドキュメントチームが忘れた未記載のパラメータはありません。仕様はリポジトリで管理され、APIと共にバージョン管理されます。破壊的変更はSemVerに従い、少なくとも90日の非推奨期間が設けられます。仕様はドキュメント内でScalarを使用してインタラクティブにレンダリングされます。APIキーを貼り付けるだけで、ブラウザを離れることなく呼び出しを試すことができます。リリースごとに同じ仕様から3つのSDK（TypeScript, Python, Go）が自動生成されるため、サーバーの実際の挙動と乖離することはありません。SDKのメソッドは型定義されたリクエストオブジェクトを受け取り、型定義されたレスポンスオブジェクトを返します。エラーも文字列ではなく型として処理されます。書き込みエンドポイントではべき等性キーがサポートされています。`Idempotency-Key`ヘッダーを渡すことで、重複作成を避け、リトライ時にレスポンスを再送できます。
CIパイプラインのための決定論的スラッグ、一括作成、およびべき等性
POST /v1/workspaces/{ws}/links はスラッグフィールドを受け取ります。リクエストした通りのスラッグを取得するか、既存のリンクIDを含む競合エラーを受け取ることができるため、パイプライン側で次のアクションを決定できます。一括作成（POST .../links/bulk）は1回の呼び出しで最大100のリンク指定を受け付けます。レスポンスには入力行ごとの結果（作成されたリンクまたはエラー）が含まれるため、一部の失敗が埋もれることはありません。どちらのエンドポイントもべき等性キーをサポートしています。同じキーで同じリクエストを再送信すれば、重複した行を作成することなく同じレスポンスが得られます。これは、デプロイ時に短縮リンクを発行するCI/CDパイプラインに最適なパターンであり、環境を問わず決定論的で、安全にリトライ可能で、一貫性があります。スラッグの名前空間はカスタムドメインごとに分かれています。2つの異なるドメインで同じスラッグを使用しても、競合せず別のリンクとして扱われます。
自動リトライとデッドレターキューを備えたHMAC署名付きWebhook
すべてのワークスペースイベント（リンク作成、クリック、削除、監査ログ、コンバージョン属性）はWebhookとして利用可能です。ペイロードは、ローテーション可能なシークレットを使用したHMAC-SHA256で署名されます。署名キーはAPIキーとは別に管理されるため、一方をローテーションしても他方が無効になることはありません。配信セマンティクスは「少なくとも1回（at-least-once）」であり、指数バックオフ（1秒、5秒、30秒、5分、30分）と設定可能なリトライ期間（デフォルト24時間）を備えています。リトライを使い果たしたイベントは、ダッシュボードで確認可能なデッドレターキューに送られ、そこから再送が可能です。大量のイベントパイプラインを扱う場合は、Kafka互換ファイアホースがHTTP配信を完全にバイパスします。クリックイベントや監査ログをストリームから直接コンシュームできます。FirehoseはBusinessプランの機能であり、Webhook配信はPro以上のプランで利用可能です。
Model Context Protocolサーバー：あらゆるMCPクライアントでElidoツールを利用可能
オープンソースのElido MCPサーバー（MITライセンス）は、リンク、QR、および分析エンドポイントを型定義されたMCPツールとして公開します。セットアップは30秒で完了します。Claude DesktopやCursorの構成にサーバーブロックを追加し、ELIDO_API_KEYを設定して再起動するだけです。ツールのカタログはサーバーから自動検出されるため、手動の定義が古くなることはありません。デフォルトでは読み取り専用スコープですが、書き込み操作はワークスペース設定で明示的に許可できます。すべてのツール呼び出しは、呼び出しキーと引数と共にワークスペース監査ログに記録されるため、エージェントによる変更を追跡可能です。サーバーはstdioおよびSSEをサポートしており、REST APIと同じレート制限やエラーコード（429でのRetry-Afterを含む）を透過的に扱うため、エージェントはクリーンにバックオフできます。ソースコードはGitHubで公開されています。一般的なフォークでは、Elido本体の更新を待たずにワークスペース固有のツールやメタデータ拡張を追加して利用されています。
Helmチャート (Apache 2.0)：自社のVPC内でリダイレクト層を運用
リダイレクト層は、すべてのリダイレクトのホットパス上にある唯一のコンポーネントです。これは単一の自己完結型バイナリであり、L2レイヤー用のインメモリのホットキャッシュ以外の実行時依存関係はありません。Helmチャートには、Kubernetesの水平ポッドオートスケーラー（HPA）向けの適切なデフォルト設定が付属しており、CPU使用率とリクエストレートに基づいてスケールします。設定は環境変数で行い、チャートにはすべての変数を網羅したドキュメント付きのvalues.yamlが含まれています。スタックの残りの部分（APIとダッシュボード）は、Elidoが管理するSaaS上に残すことができるため、すべてをセルフホストする必要はありません。一般的な構成は、リダイレクト層を自社のVPCでセルフホストし（ユーザーへの低レイテンシ化とデータ転送費用の削減）、ダッシュボードと分析にはElidoのクラウドを使用する構成です。セキュリティポリシーに応じて、ローカルのホットキャッシュの保存時暗号化のために独自のKMSを持ち込むことも可能です。Bitly（セルフホストの選択肢なし）や独自の短縮サービスをゼロから構築する場合と比較して、Helmチャートのオプションは、開発コストをかけずに最高のリダイレクトパフォーマンスと管理されたAPI surfaceを提供します。
利用するスタック
- TypeScript SDK
- Python SDK
- Go SDK
- Webhook ファイアホース
- OpenAPI 3.1 仕様
- セルフホスト用 Helm チャート
測定対象
- p50 リダイレクトレイテンシ
- キャッシュ HIT 時 5 ms
- API アップタイム SLA
- Business プランで 99.95%
- セルフホスト RTO
- 1時間未満
Elidoを活用するエンジニアリングチーム
現在、社名はプレースホルダーです。事例が公開され次第、実際の顧客名が掲載されます。
“リダイレクト層を独自のKubernetesクラスターでセルフホストし、それ以外には管理型APIを使用しています。エッジサービスをユーザーと同じリージョンに移動したことで、p50リダイレクトレイテンシが45msから6msに短縮されました。Helmチャートは非常に読みやすく、サポートに頼ることなく導入できました。”
“MCPサーバーが決め手となりました。私たちのチームは一日中Cursorで作業していますが、ワークフローを離れることなくIDE内からリリースノート用のタグ付き短縮リンクを作成できるDXの向上は、非常に大きな価値があります。”
“一括作成時のべき等性キーにより、リトライによる重複作成を心配することなくCIで短縮リンクを発行できるようになりました。型定義されたGo SDKのおかげで、パイプラインコードはコンパイル時にチェックされ、実行時のサイレントな不正リクエストも防げています。”
Elido API vs Bitly API vs 自作短縮サービス
2つの外部オプションと、自作という選択肢の比較。Bitly APIが成熟している点や、カスタム短縮サービスがコントロール面で勝る点についても正直に記載しています。
| 機能 | Elido | Bitly API | カスタム短縮サービス |
|---|---|---|---|
| API仕様フォーマット | OpenAPI 3.1、リポジトリで管理 | 独自のv4ドキュメント (OpenAPIではない) | 独自に記述 |
| ファーストパーティSDK | TypeScript, Python, Go - 仕様から生成 | JavaScript、Python、Ruby、Java | 自作が必要 |
| 書き込み時のべき等性キー | 対応 - ヘッダーベース、すべての書き込みエンドポイント | ドキュメントなし | 自作が必要 |
| 一括作成 | 1回あたり100件、行ごとの部分失敗に対応 | ネイティブの一括エンドポイントの記載なし | スキーマ、ルール共に自由 |
| Webhook配信 | 少なくとも1回、HMAC-SHA256、DLQ | Enterpriseプランで利用可能 | 自作が必要 |
| MCPサーバー | MITオープンソース、30秒で導入可能 | 提供なし | 自作が必要 |
| リダイレクト層のセルフホスト | Apache 2.0 Helmチャート | 提供なし | 完全な制御、完全なコスト |
| p50リダイレクトレイテンシ | 5 ms (キャッシュHIT時) | 同等 (エッジ配信時) | インフラに依存 |
開発者からのよくある質問
OpenAPI仕様はどこにありますか？
/docs/api-reference にあります。Scalarでインタラクティブに表示されます。生のYAMLは /openapi.yaml にあります。これはSDKの生成に使われているものと同じ仕様であり、別途管理されているドキュメントではありません。
CIで決定論的なスラッグを取得するにはどうすればよいですか？
リクエストボディで `slug` を渡してください。スラッグが既に別のリンクで使用されている場合、APIは競合するリンクのIDを含む409エラーを返します。同じ遷移先URLで使用されている場合（べき等な再作成）、既存のリンクを返します。Idempotency-Keyヘッダーを使用してリトライを安全に行ってください。
セルフホスト用のHelmチャートには何が含まれていますか？
リダイレクト層のバイナリ、ホットキャッシュ構成、HPA設定、およびすべての構成変数が文書化されたvalues.yamlが含まれています。APIやダッシュボードは含まれておらず、これらはElidoのSaaSを利用し続けることができます。Apache 2.0ライセンスであり、フォークにCLAは不要です。
ポーリングせずにクリックイベントを取得するにはどうすればよいですか？
2つのオプションがあります。Webhook（HTTPS、HMAC署名、少なくとも1回配信）またはKafka互換ファイアホース（直接コンシューマー、Businessプラン）です。Webhookは監査やアラートに適しており、FirehoseはイベントごとのHTTP配信オーバーヘッドが問題になるような大量のイベントパイプラインに適しています。
レート制限はどうなっていますか？
APIキーごとに100回/秒（持続）、200回（バースト）までです。制限に達すると429エラーとRetry-Afterヘッダーが返されます。書き込みエンドポイントは読み取りとは別にカウントされます。MCPサーバーは429をツールのエラーとして透過的に返し、SDKはRetry-Afterの値をレート制限エラーの型定義されたフィールドとして公開します。
MCPサーバーは対話型だけでなく、本番の自動化にも使用できますか？
はい。MCPサーバーは標準的なstdioまたはSSEプロセスです。スクリプト、CIステップ、またはエージェントパイプラインから呼び出すことができます。デフォルトは読み取り専用で、書き込みスコープには明示的なワークスペース設定が必要です。すべての呼び出しは監査されます。
破壊的変更のポリシーはどうなっていますか？
APIバージョンのプレフィックス（/v1/, /v2/）にSemVerを適用しています。破壊的変更には90日間の非推奨期間が設けられ、その間は両方のバージョンが並行して稼働します。非破壊的な追加（新しいフィールドやエンドポイント）は、バージョンを上げずに行われます。/changelog ですべての変更履歴と影響を受けるエンドポイントを確認できます。
実際のAPIを叩かずにローカル開発するモードはありますか？
TypeScriptおよびPython SDKは、独自のインスタンスを指すようにbaseUrlを上書きできるため、セルフホスト環境での利用に役立ちます。公式のモックサーバーはまだありません。ローカルテストには、モックではなく、テスト用のワークスペースと別のAPIキーを使用するパターンを推奨しています。これはロードマップに含まれています。