Make.com-URL-Shortener: Drei Szenarien für Kurzlinks

Ein Make.com-URL-Shortener läuft über ein einziges Modul: HTTP, Make a request. Es sendet einen POST an https://api.elido.app/v1/workspaces/{workspace_id}/links mit einem Bearer-API-Key und einem JSON-Body aus domain_id und destination_url, und Elido antwortet mit dem Slug des neuen Links. Hängen Sie diesen Slug an Ihren Hostnamen an, haben Sie einen Kurzlink. Das ist der ganze Kniff, und er funktioniert mit jedem Make-Tarif.

Wer nach einem "make short link module" sucht, erwartet meist eine gebrandete Elido-Karte in der Modulauswahl. Eine solche Karte kann noch nicht installiert werden. Deshalb baut diese Anleitung auf Makes eigener HTTP-App auf. Im Folgenden geht es um die Anfrage selbst, drei Szenarien, die ich tatsächlich ausführen würde, die Prüfung signierter Webhooks innerhalb von Make und die Credit-Kosten jedes Szenarios.

Sie sind neu bei der Elido-REST-API? Beginnen Sie mit dem Schnellstart für API und SDKs. Dort werden Tokens, Workspaces und Domains erklärt, die dieser Beitrag als bekannt voraussetzt.

Was Make heute für Elido-Kurzlinks bietet

Die kurze Antwort: die HTTP-App. Elidos offenes Repository enthält zwar den Quellcode für eine benutzerdefinierte Make-App mit einem Verbindungsmodul sowie Modulen zum Erstellen, Aktualisieren, Suchen und für Analytics und Trigger für Link-Ereignisse. Sie ist aber nicht im öffentlichen Make-App-Verzeichnis aufgeführt. Sie zu laden würde bedeuten, sie in Ihr eigenes Make-Entwicklerkonto zu übertragen und dort zu warten.

Ich würde daher vorerst darauf verzichten. Das HTTP-Modul erreicht jeden Endpunkt, lässt Sie beliebige Header setzen und übersteht Änderungen auf beiden Seiten, weil es einfach nur eine Anfrage ist. Wenn eine gelistete App veröffentlicht wird, lassen sich die folgenden Szenarien mit denselben Datenstrukturen übertragen, da beide Wege dieselben Endpunkte mit denselben Bodies und demselben API-Key aufrufen.

Hier werden ausschließlich die Standard-Apps von Make verwendet: HTTP, Webhooks, JSON, Google Sheets, RSS und Slack. Wenn Sie Plattformen vergleichen, behandelt der Leitfaden zum n8n-URL-Shortener dieselbe API in n8n. Der Zapier-Leitfaden behandelt Zapier.

Die Make-Kurzlink-Anfrage erstellen

Vor dem ersten Szenario benötigen Sie drei Dinge: einen API-Key, eine Workspace-ID und eine Domain-ID.

Erstellen Sie den Key im Elido-Dashboard unter API keys. Er beginnt mit elido_ und wird nur einmal angezeigt, also fügen Sie ihn direkt in Make ein. Wählen Sie im HTTP-Modul den Authentifizierungstyp API key und erstellen Sie einen Zugang, der Bearer elido_... in einen Header namens Authorization einträgt. Make speichert ihn als wiederverwendbaren Zugang. Das ist deutlich besser, als den Header in jedes Modul einzufügen.

Ihre Workspace-ID steht in der Dashboard-URL. Für die Domain-ID führen Sie mit Run once eine einmalige GET-Anfrage an /v1/workspaces/{workspace_id}/domains aus: Jedes Element hat eine id und einen hostname. Notieren Sie sich beide.

Konfigurieren Sie anschließend Make a request wie folgt:

Module:             HTTP > Make a request
Authentication:     API key (header Authorization = Bearer elido_...)
URL:                https://api.elido.app/v1/workspaces/1/links
Method:             POST
Headers:            Idempotency-Key = {{sha256(1.url)}}
Body content type:  application/json
Body:               {
                      "domain_id": 7,
                      "destination_url": "{{1.url}}",
                      "title": "{{1.title}}",
                      "tags": ["make"]
                    }
Parse response:     Yes

Die Antwort ist der Link-Datensatz: id, slug, destination_url, domain_id, tags und Zeitstempel. Es gibt kein fertiges Feld für die vollständige URL. Spätere Module erstellen sie daher als https://go.example.com/{{2.data.slug}} mit Ihrem eigenen Hostnamen. Lassen Sie slug weg, generiert Elido einen; fügen Sie ihn für einen individuellen hinteren Teil der URL hinzu. Die Dokumentation der HTTP-App von Make führt die übrigen Optionen auf, darunter Timeouts und Cursor-Paginierung für Listenaufrufe.

Szenario eins: URLs in einer Google-Sheets-Zeile kürzen

Die meisten Teams beginnen hier. Dieses Szenario ist auch dasjenige, das sie bei der Abrechnung überrascht. Ein Planungsblatt hat eine url-Spalte; jede neue Zeile soll in Spalte D einen Kurzlink erhalten.

Die Kette hat drei Module. Google Sheets, Watch New Rows, wird für jede seit der letzten Prüfung hinzugefügte Zeile ausgelöst. Die obige HTTP-Anfrage überträgt die url-Zelle der Zeile in destination_url. Danach schreibt Google Sheets, Update a Row, https://go.example.com/{{2.data.slug}} mithilfe der vom Trigger übergebenen Zeilennummer in dieselbe Zeile zurück.

Zwei Details sind wichtig. Setzen Sie einen Filter zwischen Trigger und HTTP-Modul, der Zeilen mit leerem url stoppt, denn leere Zeilen sind die klassische Quelle für 400er-Fehler. Behalten Sie außerdem den Idempotency-Key bei: Wenn Make eine Zeile nach einem Timeout erneut versucht, spielt derselbe Key den ersten Link erneut ab, statt einen zweiten zu erstellen. Sie möchten UTM-Parameter für jeden Link? Erstellen Sie sie vorher mit einem Set variable-Schritt im Ziel. Der Leitfaden zur UTM-Verfolgung enthält eine belastbare Benennungskonvention.

Sie fügen 3.000 Zeilen auf einmal ein? Schicken Sie sie nicht einzeln durch Make. Dafür ist der Bulk-Import aus Google Sheets gedacht, der überhaupt keine Credits kostet.

Szenario zwei: Neuer Blogbeitrag an einen Social-Scheduler

Das zweite Szenario verwandelt einen Feed in geplante Beiträge. RSS, Watch RSS feed items, prüft Ihren Blog-Feed nach einem Zeitplan. Das HTTP-Modul kürzt den Link des Elements, wobei der Beitragstitel in title und ein Tag wie rss eingetragen wird. Das dritte Modul ist die Aktion zum Erstellen eines Beitrags in Ihrem Scheduler, zum Beispiel in Buffer, mit dem Titel des Elements und der Kurz-URL als Text.

Ich füge hier gern einen Router hinzu. Ein Zweig führt zum Scheduler, ein anderer legt denselben Kurzlink in einem Slack-Kanal ab, damit das Team ihn vor der Veröffentlichung sieht. Beide Zweige verwenden den einzelnen Link aus dem HTTP-Modul wieder. Sie bezahlen also pro Element nur für einen Erstellungsaufruf und nicht für zwei.

Eine Sache habe ich auf die mühsame Art gelernt: Feeds veröffentlichen Beiträge erneut. Ein CMS, das das Datum eines alten Beitrags ändert, kann ihn wieder in den Feed schieben. Ohne Idempotency-Key erstellt das Szenario dann einen neuen Link für einen Beitrag, den Sie vor Monaten geteilt haben. Das Hashing der Element-URL wie in der obigen Konfiguration sorgt dafür, dass eine Wiederholung innerhalb von 24 Stunden die ursprüngliche Antwort erneut abspielt. Für ältere Wiederholungen benötigen Sie eine nach der URL indizierte Prüfung in einem Datenspeicher.

Sie bezahlen jemanden dafür, jeden Dienstag Links in einen Scheduler einzufügen? Erstellen Sie einen kostenlosen Elido-Workspace und richten Sie dieses Feed-Szenario in der Zeit ein, die Sie zum Lesen des nächsten Abschnitts brauchen.

Szenario drei: link.created-Webhook an Slack

Die ersten beiden Szenarien übertragen Links an Elido. Dieses hier hört zu. Immer wenn jemand im Workspace einen Link erstellt, über das Dashboard, die API oder ein anderes Szenario, veröffentlicht Make ihn in einem Audit-Kanal.

Beginnen Sie mit Webhooks, Custom webhook, und kopieren Sie die URL, die Make Ihnen gibt. Öffnen Sie in Elido Webhooks, fügen Sie einen Endpunkt mit dieser URL hinzu und aktivieren Sie link.created. Das Secret wird einmal angezeigt. Bewahren Sie es auf.

Aktivieren Sie in den erweiterten Einstellungen des Custom webhook JSON pass through und Get request headers. Sie benötigen den unveränderten Body, weil Elido timestamp.raw_body mit HMAC-SHA256 signiert und das Ergebnis als X-Webhook-Signature: v1=<hex> mit dem Zeitstempel in X-Webhook-Timestamp sendet. Ein neu serialisierter Body stimmt nicht überein. Makes sha256-Funktion nimmt ein Schlüsselargument entgegen und gibt einen HMAC zurück, sodass ein Filter die Prüfung übernehmen kann:

Filter "signature ok" (after the Custom webhook):
  v1={{sha256(TS.RAW; hex; SECRET)}}   Text operators: Equal to   SIG

TS     = {{get(map(1.headers; "value"; "name"; "x-webhook-timestamp"); 1)}}
SIG    = {{get(map(1.headers; "value"; "name"; "x-webhook-signature"); 1)}}
RAW    = {{1.value}}   (the raw body JSON pass through hands you)
SECRET = the whsec_... secret, in a custom variable if your plan has them

Nach dem Filter wandelt JSON, Parse JSON den Rohtext in Felder um, und Slack, Create a Message, veröffentlicht {{3.data.slug}} und {{3.data.destination_url}}. Die Nutzdaten enthalten type, workspace_id, data (den Link-Datensatz) und timestamp.

Es gibt kein Klickereignis, und das ist auf Elidos Seite Absicht: Webhooks decken den Lebenszyklus von Links und Workspaces ab, nicht den Traffic. Für Klickzahlen ist ein täglich geplantes Szenario die passende Lösung. Die Dokumentation der Webhooks-App von Make erklärt die Warteschlange hinter dem Custom webhook, und unser Beitrag zu Webhooks für Link-Ereignisse geht bei Nutzdaten und Zustellwiederholungen näher ins Detail.

Fehlerbehandlung und Credit-Kosten in Make

Das HTTP-Modul von Make behandelt jeden 4xx- oder 5xx-Status standardmäßig als Fehler, was genau richtig ist. Was danach geschieht, hängt vom Fehler-Handler ab, den Sie daran anhängen.

Ordnen Sie den Handler dem Statuscode zu:

• 429 oder 5xx: Fügen Sie Retry hinzu. Das fehlerhafte Bundle wird als unvollständige Ausführung abgelegt und später erneut versucht. Aktivieren Sie daher zuerst Store incomplete executions in den Szenario-Einstellungen. Der Leitfaden zum Retry-Fehler-Handler behandelt die Einstellungen für Versuche und Intervalle. Elido sendet bei Rate Limits Retry-After, und das Replay auf Basis des Keys verhindert, dass ein erneuter Erstellungsversuch ein Duplikat anlegt.
• 400, 401, 403, 409: Führen Sie keinen Retry aus. Ein 400 bedeutet, dass domain_id oder destination_url fehlt oder der Body als Formular codiert ist, 401 betrifft den Key, 403 die falsche Workspace-ID und 409 bedeutet, dass ein individueller Slug bereits vergeben ist. Leiten Sie diese Fälle mit einem Fallback-Wert an Resume weiter oder an Skip und zusätzlich per E-Mail an die für das Blatt zuständige Person.

Credits sind die andere Seite. Seit Make die Abrechnungseinheiten umgestellt hat, kostet jeder Modul-Durchlauf pro Bundle einen Credit, und ein Polling-Trigger kostet auch dann einen Credit pro Prüfung, wenn er nichts findet, wie Makes Referenz zu den Vorgängen erklärt. Diese Leerlaufkosten fallen ins Gewicht:

Makes kostenloser Tarif stellt 1.000 Credits pro Monat bereit (Stand September 2026). Der Sheets-Watcher im 15-Minuten-Takt verbraucht fast das Dreifache davon, nur indem er prüft. Stellen Sie ihn auf stündlich um. Noch besser: Verwenden Sie einen Webhook-Trigger, wenn die Quell-App einen anbietet.

Ist Make überhaupt der richtige Ort dafür? Für eine Handvoll Abläufe, die von Marketingmitarbeitern betreut werden, denke ich: ja. Sobald Sie Tausende Links am Tag erstellen, ist ein kurzes Skript gegen die Elido-API und SDKs günstiger und leichter zu debuggen, und Elido-Webhooks decken die Push-Seite ab. Der Leitfaden zu Rate Limits und Idempotenz erklärt das überall verwendete Replay-Fenster von 24 Stunden.

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

Verwandte Beiträge im Blog

• n8n-URL-Shortener: HTTP-Request-Node oder Community-Node - dieselbe API aus n8n, in der Cloud oder selbst gehostet.
• Zapier-URL-Shortener-Automatisierung - der Zapier-Weg zu denselben Aufgaben.
• Webhooks für Link-Ereignisse - Nutzdaten, Signaturen und Verhalten bei Zustellwiederholungen.
• Slack-Bot zum Kürzen von Links und Benachrichtigungen - wenn die Slack-Seite ihre eigene App verdient.
• IFTTT-URL-Shortener-Applets - dieselben Aufgaben über Telefon- und Feed-Trigger mit IFTTT-Webhooks.