IFTTT-URL-Shortener: Webhook-Applets für Elido-Kurzlinks

Ein IFTTT-URL-Shortener auf Elido basiert auf IFTTTs allgemeinem Webhooks-Dienst, weil es auf IFTTT keinen nativen Elido-Dienst gibt. Ein Applet sendet POST /v1/workspaces/{workspace_id}/links mit einem Authorization: Bearer elido_...-Header und einem JSON-Body mit domain_id und destination_url, worauf Elido den Link erstellt. In die andere Richtung sendet ein Elido-Webhook Link-Ereignisse an Ihre persönliche IFTTT-Webhooks-URL, wo sie zu Applet-Triggern werden. Webhooks benötigen IFTTT Pro. Um den erstellten Link zurückzulesen, brauchen Sie Pro+.

So sieht es ehrlich aus. Sie können mit IFTTT Links aus jedem angebotenen Trigger heraus kürzen und auf Link-Lifecycle-Ereignisse reagieren. Was Sie in einem günstigen Plan nicht tun können: den neuen Kurzlink nehmen und ihn im selben Applet verwenden. Das überrascht die meisten am ersten Tag.

Dieser Leitfaden geht bei IFTTT mehr in die Tiefe als unsere Make- und IFTTT-Rezepte, die beide Plattformen nebeneinander behandeln. Neu bei der Elido-API? Der Schnellstart für API und SDKs erklärt zuerst Schlüssel, Workspaces und Domains.

Was die IFTTT-Integration tatsächlich ist

Es sind zwei eingefügte URLs, eine pro Richtung, ohne OAuth-App dazwischen. IFTTTs Webhooks-Dienst stellt beide Hälften bereit. Seine Aktion "Make a web request" ruft die Elido-API auf. Sein Trigger "Receive a web request" wartet auf einer URL, die Ihren persönlichen Maker-Schlüssel enthält, und ein Elido-Webhook-Endpunkt kann auf diese URL zeigen.

Welche Hälfte Sie nutzen können, hängt vom IFTTT-Plan ab. Das stand auf der IFTTT-Planseite, als ich sie am 21. September 2026 geprüft habe:

Kostenlose Konten erhalten zwei Applets, aber überhaupt keine Webhooks. Ein kostenloses IFTTT-Konto kann also nicht mit Elido kommunizieren. Pro war mit 2,99 USD pro Monat und Pro+ mit 8,99 USD angegeben. Preise ändern sich, verlassen Sie sich daher eher auf die Seite als auf diesen Absatz.

Applet 1: Links mit IFTTT aus einem RSS-Feed kürzen

Das einfachste nützliche Applet verwandelt jeden neuen Blogbeitrag in einen getaggten Kurzlink, sodass der Link bereits existiert, wenn Sie ihn teilen. Es läuft in Pro.

Bevor Sie IFTTT öffnen, besorgen Sie sich drei Dinge aus Elido. Erstellen Sie unter API keys im Dashboard einen Schlüssel; er beginnt mit elido_ und wird nur einmal angezeigt. Kopieren Sie Ihre Workspace-ID aus der Dashboard-URL. Führen Sie dann einmal GET /v1/workspaces/{workspace_id}/domains aus und notieren Sie id und hostname der Domain, auf der die Links liegen sollen.

Wählen Sie in IFTTT RSS Feed als Dienst für "If This", mit dem New feed item-Trigger, und fügen Sie Ihre Feed-URL ein. Wählen Sie für "Then That" Webhooks und 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"]}

Lassen Sie slug weg, dann erzeugt Elido einen. Den Header Idempotency-Key würde ich nie weglassen. Wenn IFTTT dasselbe Element zweimal sendet, gibt Elido 24 Stunden lang die ursprüngliche Antwort erneut aus, statt einen doppelten Link zu erstellen, denn der Schlüssel ist einfach die URL des Beitrags.

Die Aktion läuft allerdings nach dem Fire-and-forget-Prinzip. IFTTTs Seite zur Make-a-web-request-Aktion führt keine Antwort-Ingredients auf, daher erreicht der neue Slug den nächsten Schritt nie. Der Link existiert in Elido, ist mit rss getaggt, und Sie kopieren ihn dort. Für viele reicht das aus. Wenn der Link automatisch irgendwo gepostet werden soll, lesen Sie weiter.

Applet 2: Den Slug mit Query und Filter Code zurücklesen

Pro+ verändert das Bild. IFTTTs Make a web request with JSON response ist eine Query, keine Aktion, und liefert zwei Ingredients zurück: Status Code und Response Body. Filter Code kann diesen Body parsen, den Slug herausziehen und die fertige Kurz-URL in die nächste Aktion des Applets schreiben, bevor IFTTT diese Aktion ausführt.

Bauen Sie das Applet mit demselben RSS-Trigger. Fügen Sie die Query mit derselben URL, denselben Headern und demselben Body wie oben hinzu. Fügen Sie dann eine Aktion hinzu, etwa Notifications, und öffnen Sie den Filter-Code-Editor:

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

Zwei Details sind wichtig. Elido beantwortet eine erfolgreiche Erstellung mit 201, nicht mit 200, testen Sie also darauf. Und die Erstellungsantwort hat kein Feld für die vollständige URL: Sie erhalten id, slug, destination_url, domain_id und Zeitstempel. Den Hostnamen Ihrer Domain setzen Sie selbst mit dem Slug zusammen, weshalb Sie ihn zuvor notiert haben. Die oben genannten Ingredient-Pfade sind diejenigen, die die IFTTT-Query-Seite dokumentiert; die Autovervollständigung des Editors zeigt dieselben Namen. Vertrauen Sie ihr, falls sie irgendwann abweichen.

Ersetzen Sie die Benachrichtigung durch eine E-Mail oder eine Sheets-Zeile. Das Muster bleibt gleich. Alles, was Text annimmt, kann den Kurzlink empfangen.

Applet 3: IFTTT-Webhooks-Warnungen für Kurzlinks aus Elido-Ereignissen

Die umgekehrte Richtung beginnt in Elido. Elido-Webhooks werden bei Workspace-Ereignissen ausgelöst, und ein IFTTT-Applet kann auf sie warten. Die Ereignisse betreffen den Lifecycle: link.created, link.updated, link.deleted, link.expired, link.cap_reached sowie einige Workspace- und Mitgliederereignisse. Ein Klickereignis gibt es nicht. "Schick mir bei jedem Klick eine SMS" ist also nicht möglich, und ehrlich gesagt würden Sie das bei einem echten Volumen auch nicht wollen.

Das nützliche Ereignis ist link.cap_reached. Setzen Sie max_clicks mit PATCH /v1/workspaces/{workspace_id}/links/{link_id} auf einem Link, und Elido gibt das Ereignis aus, sobald der Link das Limit erreicht. Eine Hintergrundprüfung läuft alle paar Minuten. Rechnen Sie mit einer etwas verspäteten Warnung.

Unter den Link-Ereignissen führt das Webhook-Formular des Dashboards nur created, updated und deleted auf. Für link.cap_reached und link.expired registrieren Sie den Endpunkt über die 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"}'

Der Ereignisname steht in der IFTTT-URL, daher entspricht ein Elido-Endpunkt einem IFTTT-Ereignis. Registrieren Sie einen zweiten Endpunkt, wenn Sie zusätzlich Ablaufwarnungen möchten.

Auf der IFTTT-Seite entscheidet die Form der Payload über den Plan. Der einfache Receive-a-web-request-Trigger stellt nur value1, value2 und value3 bereit. Elidos Payload ist ein Umschlag mit type, workspace_id, data und timestamp, daher kommen diese drei Werte leer an. In Pro funktioniert das trotzdem als einfaches Ping: "ein Link hat sein Limit erreicht, sieh nach." Der JSON-payload-Trigger - beachten Sie das /json/ in der obigen URL - übergibt Ihnen den gesamten Body als ein Ingredient. Parsen Sie ihn in Pro+:

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

Elido wiederholt eine fehlgeschlagene Zustellung bis zu dreimal im Abstand von einigen Minuten, und IFTTT antwortet mit 200, sobald es die Anfrage annimmt. Zustellungsfehler sind hier selten. Applet-Fehler treten später innerhalb von IFTTT auf, wo Elido sie nicht sehen kann.

Möchten Sie eine Limitwarnung für Ihren nächsten Giveaway-Link? Starten Sie einen kostenlosen Elido-Workspace, setzen Sie ein Klicklimit und verbinden Sie das Applet oben in etwa zehn Minuten.

Sicherheit: Schlüssel, Maker-URLs und unsignierte Zustellungen

Beide Richtungen legen ein Geheimnis in die Hände von IFTTT. Sie verdienen nicht dieselbe Aufmerksamkeit.

Der Elido-API-Schlüssel liegt im Header-Feld des Applets. Jeder, der das Applet bearbeiten kann, kann ihn lesen. Geben Sie ihm einen eigenen, für IFTTT benannten Schlüssel mit der niedrigsten Rolle, die noch Links erstellen kann, sowie einem Ablaufdatum. Wenn Sie ihn später widerrufen, wird dadurch nichts anderes beeinträchtigt. Einen Schlüssel zu verlieren, den Sie mit Ihren Abrechnungsskripten teilen, wäre ein deutlich größeres Problem.

Die Maker-URL ist die größere Gefahr. Elido signiert jede Zustellung: Ein X-Webhook-Signature: v1=<hex>-Header enthält einen HMAC-SHA256 über den Zeitstempel und den rohen Body, und ein von Ihnen kontrollierter Empfänger kann Fälschungen ablehnen. IFTTT hat keinen Schritt, der dies prüft. Das Applet wird für jeden ausgelöst, der die URL kennt, unabhängig von der Signatur.

Daher würde ich IFTTT-Applets, die von Elido-Ereignissen gespeist werden, auf Benachrichtigungen und Logs beschränken. Eine gefälschte Anfrage kann Ihr Telefon klingeln lassen. Mehr nicht. Wenn ein Ereignis etwas Wichtiges ändern soll, etwa eine Kampagne pausieren oder einen CRM-Datensatz bearbeiten, senden Sie es stattdessen an einen Empfänger, der Signaturen verifiziert. Der Beitrag zu Webhook-Ereignissen zeigt die Prüfung. Self-hosted n8n ist ein Ort, an dem Sie sie ausführen können.

Wo IFTTT nicht mehr das richtige Tool ist

IFTTT gewinnt bei Triggern, die sonst niemand hat. Standort, Telefon-Widget, Smart-Home-Sensor, Sprachassistent: Diese Dinge sind dort nativ und überall sonst umständlich. Wenn die Aufgabe lautet "wenn ich am Veranstaltungsort ankomme, erstelle den Kurzlink für heute Abend", ist es das richtige Tool, und ich würde es ohne weiteres Nachdenken verwenden.

An vier Stellen passt es nicht mehr:

• Alles mit einer Schleife. Ein Applet verarbeitet jeweils ein Trigger-Ereignis. 300 Zeilen aus einer Tabelle zu kürzen ist eine Aufgabe für den Massenimport aus Google Sheets, nicht für 300 Applet-Ausführungen.
• Retry-Logik. Wenn die Elido-API mit 429 oder 5xx antwortet, schlägt die Aktion einfach fehl und das Applet läuft weiter. Der HTTP-Request-Knoten von n8n ermöglicht Wiederholungen mit Wartezeit und leitet Fehler an eine sichtbare Stelle weiter.
• Antwortverarbeitung mit kleinem Budget. Den Slug zurückzulesen kostet Pro+. Make und Zapier liefern die Antwort in jedem kostenpflichtigen Plan, und der Zapier-Durchlauf zeigt diesen Weg von Anfang bis Ende.
• Verzweigungen. Filter Code kann eine Aktion überspringen, aber ein echtes Wenn/Dann über mehrere Dienste gehört in Make oder n8n.

Wenn Sie überhaupt Code schreiben, überspringen Sie die visuellen Tools und rufen Sie die API aus einem kleinen Skript auf. Der Leitfaden zu Rate Limits und Idempotenz behandelt die Wiederholungsregeln, die jeder Aufrufer befolgen sollte, einschließlich IFTTT. Die vollständige Liste der Endpunkte finden Sie unter Elidos API und SDKs.

Lesen Sie den Cornerstone-Artikel → Schnellstart für URL-Shortener-API und SDKs

Verwandte Beiträge im Blog

• Kurzlink-Automatisierung mit Make und IFTTT - beide Plattformen in einem Durchgang verglichen.
• n8n-URL-Shortener - der HTTP-Request-Knoten mit Wiederholungen und Idempotenz.
• URL-Shortener-Automatisierung mit Zapier - der gehostete Weg mit Antwortdaten in jedem kostenpflichtigen Plan.
• Webhooks für Link-Ereignisse - Payloads, Signaturprüfungen und Wiederholungen.
• Eine URL auf dem iPhone kürzen - der manuelle Weg, wenn ein Applet übertrieben wäre.
• URL-Shortener-Szenarien für Make.com - mehrstufige Abläufe mit Routern, Fehler-Handlern und Credit-Kosten.