Skracacz URL IFTTT: aplety Webhooks dla krótkich linków Elido

Skracacz URL IFTTT na Elido powstaje z ogólnej usługi Webhooks IFTTT, ponieważ IFTTT nie ma natywnej usługi Elido. Aplet wysyła POST /v1/workspaces/{workspace_id}/links z nagłówkiem Authorization: Bearer elido_... i treścią JSON zawierającą domain_id oraz destination_url, a Elido tworzy link. W drugą stronę webhook Elido wysyła zdarzenia linków na Twój osobisty adres URL IFTTT Webhooks, gdzie stają się wyzwalaczami apletów. Webhooki wymagają planu IFTTT Pro. Odczytanie utworzonego linku z powrotem wymaga Pro+.

Taki jest rzeczywisty kształt tego rozwiązania. Możesz skracać linki w IFTTT z dowolnego obsługiwanego wyzwalacza i reagować na zdarzenia cyklu życia linku. W tańszym planie nie możesz jednak pobrać nowego krótkiego linku i użyć go w tym samym aplecie, co zaskakuje większość osób już pierwszego dnia.

Ten przewodnik omawia IFTTT dokładniej niż nasze receptury Make i IFTTT, które pokazują obie platformy obok siebie. Dopiero poznajesz API Elido? Szybki start API i SDK najpierw wyjaśnia klucze, przestrzenie robocze i domeny.

Na czym naprawdę polega integracja z IFTTT

To dwa wklejane adresy URL, po jednym w każdym kierunku, bez aplikacji OAuth pomiędzy nimi. Obie połowy zapewnia usługa Webhooks IFTTT. Jej działanie "Make a web request" wywołuje API Elido. Jej wyzwalacz "Receive a web request" nasłuchuje adresu URL zawierającego Twój osobisty klucz Maker, a punkt końcowy webhooka Elido może wskazywać ten adres.

To, z której połowy możesz skorzystać, zależy od planu IFTTT. Oto co strona planów IFTTT podawała, gdy sprawdzałam ją 21 września 2026 roku:

Darmowe konta dostają dwa aplety i w ogóle nie mają Webhooks, więc darmowe konto IFTTT nie może komunikować się z Elido. Plan Pro kosztował według tej strony 2,99 USD miesięcznie, a Pro+ 8,99 USD. Ceny się zmieniają, więc ufaj stronie, a nie temu akapitowi.

Aplet 1: Skracanie linków z IFTTT na podstawie kanału RSS

Najprostszy użyteczny aplet zamienia każdy nowy wpis na blogu w otagowany krótki link, dzięki czemu link już istnieje, gdy przychodzi pora go udostępnić. Działa w planie Pro.

Zanim otworzysz IFTTT, przygotuj z Elido trzy rzeczy. Utwórz klucz w sekcji API keys w panelu; zaczyna się od elido_ i jest wyświetlany tylko raz. Skopiuj identyfikator swojej przestrzeni roboczej z adresu URL panelu. Następnie raz wykonaj GET /v1/workspaces/{workspace_id}/domains i zanotuj id oraz hostname domeny, na której mają znajdować się linki.

W IFTTT wybierz RSS Feed jako usługę "If This", z wyzwalaczem New feed item, i wklej adres URL kanału. W sekcji "Then That" wybierz Webhooks oraz 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"]}

Pomiń slug, a Elido wygeneruje go automatycznie. Nagłówka Idempotency-Key nigdy bym nie pomijała. Jeśli IFTTT wyśle ten sam element dwa razy, Elido przez 24 godziny odtworzy pierwotną odpowiedź zamiast utworzyć duplikat linku, ponieważ kluczem jest po prostu URL wpisu.

To jednak działanie typu fire-and-forget. Strona działania Make a web request IFTTT nie wymienia żadnych składników odpowiedzi, więc nowy slug nigdy nie trafia do następnego kroku. Link istnieje w Elido i ma tag rss, a Ty kopiujesz go stamtąd. Dla wielu osób to wystarczy. Jeśli chcesz automatycznie publikować link gdzieś indziej, czytaj dalej.

Aplet 2: Odczytywanie sluga za pomocą zapytania i filter code

Pro+ zmienia sytuację. Make a web request with JSON response IFTTT to zapytanie, a nie działanie, i zwraca dwa składniki: Status Code oraz Response Body. Filter code może przeanalizować tę treść, wyciągnąć z niej slug i wpisać gotowy krótki URL do dowolnego kolejnego działania w aplecie, zanim IFTTT je uruchomi.

Zbuduj aplet z tym samym wyzwalaczem RSS. Dodaj zapytanie z tym samym adresem URL, nagłówkami i treścią co wyżej. Następnie dodaj działanie, na przykład Notifications, i otwórz edytor filter code:

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

Liczą się dwa szczegóły. Elido odpowiada kodem 201 po pomyślnym utworzeniu, a nie 200, więc sprawdzaj właśnie tę wartość. Odpowiedź tworzenia nie ma też pola z pełnym URL-em: otrzymujesz id, slug, destination_url, domain_id i znaczniki czasu. Samodzielnie łączysz nazwę hosta swojej domeny ze slugiem, dlatego trzeba było zanotować ją wcześniej. Ścieżki składników powyżej pochodzą ze strony zapytania IFTTT; autouzupełnianie w edytorze pokazuje te same nazwy, więc jeśli kiedyś będą się różnić, zaufaj edytorowi.

Zamień powiadomienie na wiadomość e-mail albo wiersz w Sheets. Wzorzec pozostaje ten sam. Każde działanie przyjmujące tekst może otrzymać krótki link.

Aplet 3: Alerty krótkich linków IFTTT Webhooks ze zdarzeń Elido

Kierunek odwrotny zaczyna się w Elido. Webhooki Elido uruchamiają się dla zdarzeń przestrzeni roboczej, a aplet IFTTT może ich nasłuchiwać. Są to zdarzenia cyklu życia: link.created, link.updated, link.deleted, link.expired, link.cap_reached oraz kilka zdarzeń przestrzeni roboczej i członków. Nie ma zdarzenia kliknięcia, więc "wyślij mi SMS przy każdym kliknięciu" nie jest możliwe i, szczerze mówiąc, przy jakimkolwiek rzeczywistym natężeniu ruchu nie byłoby pożądane.

Najbardziej użyteczne jest link.cap_reached. Ustaw max_clicks dla linku za pomocą PATCH /v1/workspaces/{workspace_id}/links/{link_id}, a Elido wyśle zdarzenie po osiągnięciu przez link limitu. Sprawdzenie w tle uruchamia się co kilka minut. Alert może przyjść z niewielkim opóźnieniem.

Wśród zdarzeń linków formularz webhooków w panelu wymienia tylko utworzenie, aktualizację i usunięcie. W przypadku link.cap_reached i link.expired zarejestruj punkt końcowy przez 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"}'

Nazwa zdarzenia znajduje się w adresie URL IFTTT, więc jeden punkt końcowy Elido mapuje się na jedno zdarzenie IFTTT. Zarejestruj drugi punkt końcowy, jeśli chcesz również alertów o wygaśnięciu.

Po stronie IFTTT o planie decyduje kształt ładunku. Zwykły wyzwalacz Receive a web request udostępnia tylko value1, value2 i value3. Ładunek Elido jest kopertą z polami type, workspace_id, data i timestamp, więc te trzy wartości docierają puste. W planie Pro nadal działa to jako zwykły sygnał: "link osiągnął limit, sprawdź to." Wyzwalacz ładunku JSON, zwróć uwagę na /json/ w powyższym adresie URL, przekazuje całe body jako jeden składnik. Przeanalizuj je w Pro+:

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

Elido ponawia nieudaną dostawę do trzech razy, w odstępach kilku minut, a IFTTT odpowiada kodem 200, gdy tylko przyjmie żądanie. Błędy dostawy są tu rzadkie. Błędy apletów pojawiają się później, wewnątrz IFTTT, gdzie Elido ich nie widzi.

Chcesz alertu o limicie dla następnego linku do rozdania? Uruchom bezpłatną przestrzeń roboczą Elido, ustaw limit kliknięć i skonfiguruj powyższy aplet w około dziesięć minut.

Bezpieczeństwo: klucze, adresy URL Maker i niepodpisane dostawy

W obu kierunkach IFTTT otrzymuje sekret. Nie wszystkie wymagają jednakowego poziomu ostrożności.

Klucz API Elido znajduje się w polu nagłówków apletu. Każdy, kto może edytować ten aplet, może go odczytać. Nadaj mu osobny klucz, nazwany na cześć IFTTT, z najniższą rolą, która nadal pozwala tworzyć linki, oraz z datą wygaśnięcia. Późniejsze odwołanie klucza nie zepsuje wtedy niczego innego. Utrata klucza współdzielonego ze skryptami rozliczeniowymi byłaby znacznie poważniejszym problemem.

Adres URL Maker jest ważniejszy. Elido podpisuje każdą dostawę: nagłówek X-Webhook-Signature: v1=<hex> zawiera HMAC-SHA256 obliczony na podstawie znacznika czasu i surowej treści, a kontrolowany przez Ciebie odbiorca może odrzucać fałszerstwa. IFTTT nie ma kroku, który go sprawdza. Aplet uruchomi się dla każdego, kto zna adres URL, niezależnie od podpisu.

Dlatego aplety IFTTT zasilane zdarzeniami Elido ograniczyłabym do powiadomień i logów. Sfałszowane żądanie może sprawić, że telefon zawibruje. Nic gorszego. Jeśli zdarzenie powinno zmienić coś ważnego, na przykład wstrzymać kampanię albo edytować rekord CRM, wyślij je do odbiorcy, który weryfikuje podpisy. Opis zdarzeń webhooków pokazuje tę weryfikację. Samodzielnie hostowane n8n to jedno z miejsc, w których możesz ją uruchomić.

Kiedy IFTTT przestaje być właściwym narzędziem

IFTTT wygrywa dzięki wyzwalaczom, których nie ma nigdzie indziej. Lokalizacja, widżet telefonu, czujnik inteligentnego domu, asystent głosowy: tam są natywne, a wszędzie indziej bywają kłopotliwe. Jeśli zadanie brzmi "gdy dotrę na miejsce, utwórz krótki link na dzisiejszy wieczór", to właściwe narzędzie i użyłabym go bez wahania.

Przestaje pasować w czterech sytuacjach:

• Cokolwiek z pętlą. Aplet obsługuje jedno zdarzenie wyzwalacza naraz. Skrócenie 300 wierszy z arkusza to zadanie dla importu zbiorczego z Google Sheets, a nie 300 uruchomień apletu.
• Logika ponawiania. Gdy API Elido odpowie kodem 429 albo 5xx, działanie po prostu kończy się błędem, a aplet idzie dalej. Węzeł HTTP Request w n8n pozwala ponawiać próbę po odczekaniu i kierować błędy w widoczne miejsce.
• Przetwarzanie odpowiedzi przy ograniczonym budżecie. Odczytanie sluga z powrotem kosztuje Pro+. Make i Zapier udostępniają odpowiedź w każdym płatnym planie, a opis konfiguracji Zapier pokazuje tę ścieżkę od początku do końca.
• Rozgałęzienia. Filter code może pominąć działanie, ale prawdziwe if/else między kilkoma usługami należy zbudować w Make albo n8n.

Jeśli w ogóle piszesz kod, pomiń narzędzia wizualne i wywołaj API z małego skryptu. Przewodnik po limitach i idempotencji opisuje zasady ponawiania, których powinien przestrzegać każdy klient, także IFTTT. Pełną listę punktów końcowych znajdziesz w API i SDK Elido.

Przeczytaj wpis cornerstone → Szybki start API i SDK skracacza URL

Powiązane na blogu

• Automatyzacja krótkich linków z Make i IFTTT - porównanie obu platform w jednym miejscu.
• Skracacz URL n8n - węzeł HTTP Request z ponawianiem i idempotencją.
• Automatyzacja skracacza URL w Zapier - hostowana ścieżka z danymi odpowiedzi w każdym płatnym planie.
• Webhooki dla zdarzeń linków - ładunki, weryfikacja podpisów i ponowienia dostaw.
• Skracanie URL-a na iPhonie - ręczna ścieżka, gdy aplet byłby przesadą.
• Scenariusze skracacza URL w Make.com - wieloetapowe przepływy z routerami, obsługą błędów i kosztami kredytów.