IFTTT URL短縮サービス: Elido短縮リンク用Webhookアプレット

ElidoでIFTTT URL短縮サービスを構築するには、IFTTTにネイティブなElidoサービスがないため、IFTTTの汎用Webhooksサービスを使います。アプレットはAuthorization: Bearer elido_...ヘッダーとdomain_idおよびdestination_urlを含むJSONボディを付けてPOST /v1/workspaces/{workspace_id}/linksを送信し、Elidoがリンクを作成します。逆方向では、Elido webhookが個人用IFTTT Webhooks URLへリンクイベントを投稿し、そこでアプレットのトリガーになります。WebhooksにはIFTTT Proが必要です。作成したリンクを読み戻すにはPro+が必要です。

これが実際の構成です。IFTTTが提供するどのトリガーからでもリンクを短縮でき、リンクのライフサイクルイベントにも反応できます。ただし、安価なプランでは新しい短縮リンクを取得して同じアプレットで使うことができません。初日に多くの人が驚く点です。

このガイドでは、両方のプラットフォームを並べて扱うMakeとIFTTTのレシピよりも、IFTTTについて詳しく説明します。Elido APIを初めて使う方は、まずAPIとSDKのクイックスタートでキー、ワークスペース、ドメインを確認してください。

IFTTT連携の実際の仕組み

OAuthアプリを間に挟まず、方向ごとに1つずつURLを貼り付けます。両方の部分を提供するのがIFTTTのWebhooksサービスです。その「Make a web request」アクションがElido APIを呼び出します。「Receive a web request」トリガーは個人用Makerキーを含むURLを監視し、Elidoのwebhookエンドポイントからそこへ送信できます。

利用できる部分はIFTTTのプランによって異なります。2026年9月21日に確認したとき、IFTTTのプランページには次のように記載されていました。

Freeアカウントには2つのアプレットが付属しますが、Webhooksはまったく使えないため、FreeのIFTTTアカウントからElidoへ接続することはできません。Proは月額2.99 USD、Pro+は8.99 USDと記載されていました。価格は変わるため、この段落よりページの記載を優先してください。

アプレット1: RSSフィードからIFTTTでリンクを短縮する

最も簡単で役立つアプレットは、新しいブログ記事ごとにタグ付き短縮リンクを作成します。共有する時点ですでにリンクが存在する状態になります。Proで動作します。

IFTTTを開く前に、Elidoから3つの情報を集めてください。ダッシュボードのAPI keysでキーを作成します。キーはelido_で始まり、一度だけ表示されます。ダッシュボードURLからワークスペースIDをコピーします。次にGET /v1/workspaces/{workspace_id}/domainsを1回実行し、リンクを置くドメインのidとhostnameを控えます。

IFTTTでRSS Feedを「If This」サービスとして選び、New feed itemトリガーを設定してフィードURLを貼り付けます。「Then That」ではWebhooksとMake a web requestを選びます。

URL:                https://api.elido.app/v1/workspaces/1/links
Method:             POST
Content Type:       application/json
Additional Headers: Authorization: Bearer elido_xxxxxxxx
                    Idempotency-Key: {{EntryUrl}}
Body:               {"domain_id": 7,
                     "destination_url": "{{EntryUrl}}",
                     "title": "{{EntryTitle}}",
                     "tags": ["ifttt", "rss"]}

slugは省略してください。Elidoが生成します。Idempotency-Keyヘッダーは、私なら決して省略しない行です。IFTTTが同じ項目を2回送っても、キーが単純に記事のURLであるため、Elidoは重複リンクを発行せず、24時間にわたって元のレスポンスをリプレイします。

ただし、このアクションは送信して完了します。IFTTTのMake a web requestアクションページにはレスポンスの材料が記載されていないため、新しいスラッグが次のステップに届くことはありません。リンクはElidoに存在し、rssのタグが付きます。そこからコピーしてください。多くの人にとっては、それで問題ありません。リンクをどこかへ自動投稿したい場合は、読み進めてください。

アプレット2: クエリとフィルターコードでスラッグを読み戻す

Pro+では状況が変わります。IFTTTのMake a web request with JSON responseはアクションではなくクエリで、Status CodeとResponse Bodyという2つの材料を返します。フィルターコードでボディを解析し、そこからスラッグを取り出して、IFTTTが次のアクションを実行する前に、アプレット内で続く任意のアクションへ完成した短縮URLを書き込めます。

同じRSSトリガーでアプレットを構築します。上記と同じURL、ヘッダー、ボディでクエリを追加します。次に、例えばNotificationsなどのアクションを追加して、フィルターコードエディターを開きます。

const res = MakerWebhooks.makeWebRequestQueryJson;
if (res.StatusCode != "201") {
  IfNotifications.sendNotification.skip("Elido returned " + res.StatusCode);
} else {
  const link = JSON.parse(res.ResponseBody);
  IfNotifications.sendNotification.setMessage(
    "Short link ready: https://go.example.com/" + link.slug,
  );
}

重要な点が2つあります。Elidoは作成成功時に200ではなく201を返すため、その値をテストしてください。また、作成レスポンスには完全なURLのフィールドがありません。取得できるのはid、slug、destination_url、domain_id、タイムスタンプです。先ほど控えた理由は、ドメインのホスト名とスラッグを自分で結合するためです。上記の材料パスはIFTTTのクエリページに記載されているものです。エディターの自動補完にも同じ名前が表示されるため、もし違いがあればそちらを信頼してください。

通知をメールやSheetsの行に置き換えてください。パターンは同じです。テキストを受け取れるものなら、短縮リンクを渡せます。

アプレット3: ElidoイベントからIFTTT Webhooksで短縮リンクのアラートを送る

逆方向はElidoから始まります。Elidoのwebhookはワークスペースイベントで発火し、IFTTTアプレットがそれを監視できます。イベントはライフサイクルイベントです。link.created、link.updated、link.deleted、link.expired、link.cap_reachedのほか、いくつかのワークスペースおよびメンバーイベントがあります。クリックイベントはないため、「クリックのたびにメッセージを送る」ことはできません。正直なところ、実際の件数が多ければ、そうしたいとは思わないでしょう。

役立つのはlink.cap_reachedです。PATCH /v1/workspaces/{workspace_id}/links/{link_id}でリンクにmax_clicksを設定すると、リンクが上限に達した時点でElidoがイベントを発行します。バックグラウンドチェックは数分ごとに実行されます。アラートは少し遅れて届くと考えてください。

リンクイベントのうち、ダッシュボードのwebhookフォームに表示されるのはcreated、updated、deletedだけです。link.cap_reachedとlink.expiredについては、APIからエンドポイントを登録してください。

curl -X POST https://api.elido.app/v1/workspaces/1/webhooks \
  -H "Authorization: Bearer $ELIDO_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://maker.ifttt.com/trigger/elido_cap/json/with/key/YOUR_MAKER_KEY",
       "events": ["link.cap_reached"],
       "description": "IFTTT cap alert"}'

イベント名はIFTTT URLに含まれるため、1つのElidoエンドポイントが1つのIFTTTイベントに対応します。期限切れのアラートも必要な場合は、2つ目のエンドポイントを登録してください。

IFTTT側では、ペイロードの形式によって必要なプランが決まります。通常のReceive a web requestトリガーが公開するのはvalue1、value2、value3だけです。Elidoのペイロードはtype、workspace_id、data、timestampを含むエンベロープなので、これら3つの値は空で届きます。Proでも、単純な通知としては使えます。「リンクが上限に達したので確認してください」という合図です。JSON payloadトリガーは、上のURLにある/json/に注目してください。ボディ全体を1つの材料として渡します。Pro+で解析してください。

const evt = JSON.parse(MakerWebhooks.jsonEvent.JsonPayload);
IfNotifications.sendNotification.setMessage(
  "Link " + evt.data.slug + " hit its cap at " + evt.data.clicks + " clicks",
);

Elidoは失敗した配信を数分間隔で最大3回リトライし、IFTTTはリクエストを受け付けるとすぐに200を返します。ここで配信が失敗することはまれです。アプレットの失敗はその後IFTTT内部で発生するため、Elidoからは確認できません。

次のプレゼント用リンクに上限アラートを設定しませんか。無料のElidoワークスペースを開始し、クリック上限を設定して、約10分で上のアプレットを接続できます。

セキュリティ: キー、Maker URL、署名なしの配信

どちらの方向でも、IFTTTに秘密情報を預けることになります。ただし、同じ程度に心配する必要はありません。

Elido API keyはアプレットのヘッダーフィールドにあります。そのアプレットを編集できる人なら誰でも読み取れます。IFTTT用として名前を付けた専用キーを用意し、リンクを作成できる最低限のロールと有効期限を設定してください。後で取り消しても、ほかの機能には影響しません。請求スクリプトと共有しているキーを失うことのほうが、はるかに大きな問題です。

Maker URLのほうが重要です。Elidoはすべての配信に署名します。X-Webhook-Signature: v1=<hex>ヘッダーにはタイムスタンプと生のボディに対するHMAC-SHA256が含まれ、管理下の受信側なら偽造を拒否できます。IFTTTにはそれを検証するステップがありません。署名の有無にかかわらず、URLを知っている人ならアプレットを発火できます。

そのため、Elidoイベントを受け取るIFTTTアプレットは通知とログに限定します。偽造リクエストで電話を鳴らされることはありますが、それ以上のことは起きません。キャンペーンの一時停止やCRMレコードの編集など、重要な変更をイベントで行う場合は、代わりに署名を検証する受信側へ送ってください。webhook events write-upで検証方法を説明しています。セルフホスト型n8nは、その受信側を動かす場所の1つです。

IFTTTが適したツールではなくなる場面

IFTTTは、ほかのサービスにはないトリガーに強みがあります。位置情報、電話のウィジェット、スマートホームセンサー、音声アシスタントなどはIFTTTにネイティブ対応しており、ほかでは扱いにくいものです。「会場に着いたら今夜の短縮リンクを作る」という仕事なら適切なツールなので、迷わず使います。

次の4つの場面では合わなくなります。

• ループが必要なもの。 アプレットは一度に1つのトリガーイベントを処理します。シートの300行を短縮するなら、300回のアプレット実行ではなく、Google Sheetsからの一括インポートを使う仕事です。
• リトライロジック。 Elido APIが429または5xxを返すと、アクションは失敗してアプレットは先へ進みます。n8nのHTTP Requestノードなら、待機を挟んでリトライし、エラーを確認できる場所へ送れます。
• 予算を抑えたレスポンス処理。 スラッグの読み戻しにはPro+が必要です。MakeとZapierは有料プランならすべてレスポンスを取得でき、Zapierの手順で最初から最後まで確認できます。
• 分岐。 フィルターコードでアクションをスキップすることはできますが、複数のサービスにまたがる本格的なif/elseはMakeまたはn8nで扱うべきです。

コードを書くのであれば、ビジュアルツールを使わず、小さなスクリプトからAPIを呼び出してください。レート制限と冪等性のガイドでは、IFTTTを含むすべての呼び出し元が従うべきリトライルールを説明しています。エンドポイント一覧はElidoのAPIとSDKを参照してください。

コーナーストーン記事を読む → URL短縮サービスAPIとSDKのクイックスタート

ブログ内の関連記事

• MakeとIFTTTによる短縮リンクの自動化 - 両方のプラットフォームをまとめて比較します。
• n8n URL短縮サービス - リトライと冪等性に対応したHTTP Requestノードです。
• ZapierによるURL短縮の自動化 - すべての有料プランでレスポンスデータを取得できるホスト型の方法です。
• リンクイベント用webhook - ペイロード、署名検証、リトライについて説明します。
• iPhoneでURLを短縮する - アプレットを使うほどではない場合の手動の方法です。
• Make.comのURL短縮サービスシナリオ - ルーター、エラーハンドラー、クレジットコストを含む複数ステップのフローです。