Skracacz adresów URL Make.com: trzy scenariusze krótkich linków

Skracacz adresów URL Make.com działa na jednym module: HTTP, Make a request. Wysyła żądanie POST do https://api.elido.app/v1/workspaces/{workspace_id}/links z kluczem API Bearer i treścią JSON zawierającą domain_id oraz destination_url, a Elido odpowiada slugiem nowego linku. Połącz ten slug z nazwą hosta i masz krótki link. Na tym polega cały trik, który działa w każdym planie Make.

Osoby szukające hasła "make short link module" zwykle oczekują firmowej karty Elido w selektorze modułów. Nie ma jeszcze czego instalować. Dlatego ten poradnik korzysta z własnej aplikacji HTTP Make. Poniżej znajdziesz samo żądanie, trzy scenariusze, które sama rzeczywiście uruchomiłabym, sposób weryfikacji podpisanych webhooków w Make oraz koszt każdego scenariusza w kredytach.

Nie znasz jeszcze REST API Elido? Zacznij od szybkiego startu z API i SDK. Wyjaśnia on tokeny, obszary robocze i domeny, które w tym wpisie traktuję jako znane.

Co Make oferuje dziś dla krótkich linków Elido

Krótka odpowiedź: aplikację HTTP. Otwarte repozytorium Elido rzeczywiście zawiera kod źródłowy niestandardowej aplikacji Make z modułami połączenia, tworzenia, aktualizacji, wyszukiwania i analityki oraz wyzwalaczami zdarzeń linków. Nie ma jej jednak w publicznym katalogu aplikacji Make. Załadowanie jej oznaczałoby umieszczenie jej na własnym koncie deweloperskim Make i samodzielne utrzymywanie.

Na razie sama bym z niej nie korzystała. Moduł HTTP dociera do każdego endpointu, pozwala ustawić dowolny nagłówek i przetrwa zmiany po obu stronach, ponieważ jest po prostu żądaniem. Gdy pojawi się aplikacja w katalogu, poniższe scenariusze można przenieść do niej bez zmiany kształtów danych, bo obie ścieżki trafiają do tych samych endpointów, z tymi samymi treściami i tym samym kluczem API.

Wszystko tutaj korzysta ze standardowych aplikacji Make: HTTP, Webhooks, JSON, Google Sheets, RSS i Slack. Jeśli porównujesz platformy, poradnik skracacza adresów URL dla n8n opisuje to samo API w n8n. Przewodnik po Zapier dotyczy Zapiera.

Budowanie żądania krótkiego linku Make

Przed pierwszym scenariuszem potrzebujesz trzech rzeczy: klucza API, identyfikatora obszaru roboczego i identyfikatora domeny.

Utwórz klucz w dashboardzie Elido, w sekcji API keys. Zaczyna się od elido_ i jest wyświetlany tylko raz, więc od razu wklej go do Make. W module HTTP wybierz typ uwierzytelniania API key i utwórz poświadczenie, które umieszcza Bearer elido_... w nagłówku o nazwie Authorization. Make przechowuje je jako poświadczenie wielokrotnego użytku. To znacznie lepsze niż wklejanie nagłówka do każdego modułu.

Identyfikator obszaru roboczego znajduje się w adresie URL dashboardu. Aby uzyskać identyfikator domeny, wykonaj jednorazowe żądanie GET do /v1/workspaces/{workspace_id}/domains, używając Run once: każdy element ma id i hostname. Zapisz obie wartości.

Następnie skonfiguruj Make a request w ten sposób:

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

Odpowiedź to rekord linku: id, slug, destination_url, domain_id, tags i znaczniki czasu. Nie ma gotowego pola z pełnym adresem URL, więc kolejne moduły budują go jako https://go.example.com/{{2.data.slug}}, używając własnej nazwy hosta. Pozostaw slug puste, a Elido wygeneruje go automatycznie; dodaj go, jeśli chcesz mieć własną końcówkę. Dokumentacja aplikacji HTTP Make zawiera pozostałe opcje, w tym limity czasu i stronicowanie z kursorem przy wywołaniach list.

Scenariusz pierwszy: skracanie adresów URL w wierszu Google Sheets

Większość zespołów zaczyna właśnie tutaj. To także scenariusz, który zaskakuje na rachunku. Arkusz planowania ma kolumnę url, a każdy nowy wiersz powinien otrzymać krótki link zapisany w kolumnie D.

Łańcuch ma trzy moduły. Google Sheets, Watch New Rows, uruchamia się dla każdego wiersza dodanego od ostatniego sprawdzenia. Powyższe żądanie HTTP mapuje komórkę url wiersza na destination_url. Następnie Google Sheets, Update a Row, zapisuje https://go.example.com/{{2.data.slug}} z powrotem w tym samym wierszu, używając numeru wiersza przekazanego przez wyzwalacz.

Liczą się dwa szczegóły. Umieść między wyzwalaczem a modułem HTTP filtr, który zatrzyma wiersze z pustym url, ponieważ puste wiersze są klasycznym źródłem błędów 400. Zachowaj też Idempotency-Key: jeśli Make ponowi próbę dla wiersza po przekroczeniu limitu czasu, ten sam klucz odtworzy pierwszy link zamiast utworzyć jego kopię. Chcesz mieć parametry UTM w każdym linku? Najpierw dodaj je do celu za pomocą kroku Set variable. Poradnik śledzenia UTM zawiera sprawdzoną konwencję nazewniczą.

Wklejasz naraz 3000 wierszy? Nie przepuszczaj ich przez Make pojedynczo. Do tego służy import zbiorczy z Google Sheets, który nie kosztuje żadnych kredytów.

Scenariusz drugi: nowy wpis na blogu w harmonogramie publikacji społecznościowych

Drugi scenariusz zamienia kanał na zaplanowane posty. RSS, Watch RSS feed items, sprawdza kanał bloga zgodnie z harmonogramem. Moduł HTTP skraca link elementu, mapując tytuł wpisu na title i dodając tag, na przykład rss. Trzeci moduł to akcja tworzenia posta w używanym harmonogramie (na przykład w Bufferze), z tytułem elementu i krótkim adresem URL jako treścią.

Lubię dodawać tutaj router. Jedna gałąź prowadzi do harmonogramu, a druga umieszcza ten sam krótki link na kanale Slack, żeby zespół zobaczył go przed publikacją. Obie gałęzie wykorzystują ten sam link z modułu HTTP, więc płacisz za jedno wywołanie tworzenia na element, a nie za dwa.

Jedną rzecz poznałam w mało przyjemny sposób: kanały publikują ponownie. CMS, który zmieni datę starego wpisu, może wprowadzić go z powrotem do kanału, a bez Idempotency-Key scenariusz utworzy nowy link do wpisu udostępnionego kilka miesięcy wcześniej. Haszowanie adresu URL elementu, tak jak w powyższej konfiguracji, sprawia, że powtórzenie w ciągu 24 godzin odtworzy pierwotną odpowiedź. Starsze powtórzenia wymagają sprawdzenia magazynu danych po kluczu będącym adresem URL.

Płacisz komuś za cotygodniowe, wtorkowe wklejanie linków do harmonogramu? Utwórz bezpłatny obszar roboczy Elido i skonfiguruj ten scenariusz kanału w czasie potrzebnym na przeczytanie następnej sekcji.

Scenariusz trzeci: webhook link.created do Slacka

Dwa pierwsze scenariusze wysyłają linki do Elido. Ten nasłuchuje. Gdy ktokolwiek w obszarze roboczym utworzy link z dashboardu, API albo innego scenariusza, Make opublikuje go na kanale audytowym.

Zacznij od Webhooks, Custom webhook i skopiuj adres URL podany przez Make. W Elido otwórz Webhooks, dodaj endpoint z tym adresem URL i zaznacz link.created. Sekret pojawi się tylko raz. Zachowaj go.

W ustawieniach zaawansowanych Custom webhook włącz JSON pass through i Get request headers. Potrzebujesz niezmienionej treści, ponieważ Elido podpisuje timestamp.raw_body za pomocą HMAC-SHA256 i wysyła wynik jako X-Webhook-Signature: v1=<hex>, z sygnaturą czasową w X-Webhook-Timestamp. Ponownie zserializowana treść nie będzie pasować. Funkcja sha256 Make przyjmuje argument klucza i zwraca HMAC, więc filtr może wykonać sprawdzenie:

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

Po filtrze JSON, Parse JSON zamienia surowy tekst na pola, a Slack, Create a Message, publikuje {{3.data.slug}} i {{3.data.destination_url}}. Ładunek zawiera type, workspace_id, data (rekord linku) i timestamp.

Nie ma zdarzenia kliknięcia i jest to zamierzone po stronie Elido: webhooki obejmują cykl życia linków i obszarów roboczych, a nie ruch. Do liczb dotyczących kliknięć najlepiej nadaje się codzienny zaplanowany scenariusz. Dokumentacja aplikacji Webhooks Make wyjaśnia kolejkę stojącą za Custom webhook, a nasz tekst o webhookach dla zdarzeń linków dokładniej omawia ładunki i ponowienia dostarczenia.

Obsługa błędów i koszty kredytów w Make

Moduł HTTP Make domyślnie traktuje każdy błąd 4xx lub 5xx jako błąd, czego właśnie potrzebujesz. To, co stanie się później, zależy od dołączonego modułu obsługi błędów.

Przypisz moduł obsługi do kodu stanu:

• 429 lub 5xx: dołącz Retry. Przenosi on nieudany pakiet do nieukończonego wykonania i próbuje ponownie później, dlatego najpierw włącz Store incomplete executions w ustawieniach scenariusza. Poradnik modułu obsługi błędów Retry opisuje ustawienia prób i odstępów. Elido wysyła Retry-After przy limitach szybkości, a odtwarzanie oparte na kluczu sprawia, że ponowione tworzenie nigdy nie duplikuje linku.
• 400, 401, 403, 409: nie ponawiaj próby. Błąd 400 oznacza brak domain_id albo treść zakodowaną jako formularz, 401 dotyczy klucza, 403 oznacza nieprawidłowy identyfikator obszaru roboczego, a 409 oznacza, że własny slug jest już zajęty. Skieruj te błędy do Resume z wartością zastępczą albo do Skip wraz z wiadomością e-mail do osoby odpowiedzialnej za arkusz.

Kredyty to druga połowa rachunku. Odkąd Make zmienił jednostki rozliczeniowe, każde uruchomienie modułu kosztuje jeden kredyt na pakiet, a wyzwalacz odpytywania kosztuje jeden kredyt za każde sprawdzenie, nawet gdy niczego nie znajdzie, jak wyjaśnia dokumentacja operacji Make. To właśnie ten koszt bezczynności daje się we znaki:

Bezpłatny plan Make daje 1000 kredytów miesięcznie (sprawdzone we wrześniu 2026 roku). Obserwator Sheets działający co 15 minut zużywa prawie trzy razy tyle tylko na samo sprawdzanie. Wydłuż interwał do godziny. Jeszcze lepiej użyj wyzwalacza webhook, gdy aplikacja źródłowa go oferuje.

Czy Make w ogóle jest właściwym miejscem dla tego rozwiązania? Dla kilku przepływów należących do zespołu marketingowego - moim zdaniem tak. Gdy tworzysz tysiące linków dziennie, krótki skrypt korzystający z API i SDK Elido jest tańszy i łatwiejszy w debugowaniu, a webhooki Elido obsługują stronę wysyłania. Poradnik o limitach szybkości i idempotencji wyjaśnia używane wszędzie okno odtwarzania trwające 24 godziny.

Przeczytaj wpis cornerstone → Szybki start z API i SDK skracacza adresów URL

Powiązane wpisy na blogu

• Skracacz adresów URL n8n: węzeł HTTP Request czy węzeł społecznościowy - to samo API w n8n, w chmurze lub self-hosted.
• Automatyzacja skracania adresów URL w Zapierze - ścieżka Zapiera do tych samych zadań.
• Webhooki dla zdarzeń linków - ładunki, podpisy i zachowanie przy ponowieniach.
• Bot Slacka do skracania linków i alertów - gdy część slackowa zasługuje na własną aplikację.
• Aplety skracacza adresów URL IFTTT - te same zadania uruchamiane z telefonu i kanałów, przez webhooki IFTTT.