Скорочувач URL IFTTT: applet Webhooks для коротких посилань Elido

Скорочувач URL IFTTT на Elido будується на універсальному сервісі Webhooks IFTTT, оскільки в IFTTT немає нативного сервісу Elido. Applet надсилає POST /v1/workspaces/{workspace_id}/links із заголовком Authorization: Bearer elido_... і тілом JSON, що містить domain_id та destination_url, а Elido створює посилання. У зворотному напрямку вебхук Elido надсилає події посилань на вашу особисту URL-адресу Webhooks IFTTT, де вони стають trigger для applet. Для Webhooks потрібен IFTTT Pro. Щоб прочитати створене посилання у відповідь, потрібен Pro+.

Ось як це працює насправді. Ви можете скорочувати посилання через IFTTT із будь-якого trigger, який він пропонує, і реагувати на події життєвого циклу посилань. Але на дешевому плані не можна взяти нове коротке посилання й використати його в тому самому applet, що дивує більшість людей у перший день.

Цей посібник глибше розглядає IFTTT, ніж наш матеріал рецепти Make та IFTTT, де обидві платформи описано поруч. Ще не знайомі з API Elido? У короткому посібнику з API та SDK спочатку пояснено ключі, робочі простори та домени.

Що насправді являє собою інтеграція IFTTT

Це дві вставлені URL-адреси, по одній у кожному напрямку, без OAuth app між ними. Сервіс Webhooks IFTTT забезпечує обидві частини. Його action "Make a web request" викликає API Elido. Його trigger "Receive a web request" слухає URL-адресу, що містить ваш особистий Maker key, і на неї можна вказати кінцеву точку вебхука Elido.

Яку частину ви можете використовувати, залежить від плану IFTTT. Ось що було зазначено на сторінці планів IFTTT, коли я перевіряла її 21 вересня 2026 року:

Безкоштовні облікові записи отримують два applet і взагалі не мають Webhooks, тому безкоштовний обліковий запис IFTTT не може взаємодіяти з Elido. Для Pro було вказано ціну 2,99 USD на місяць, а для Pro+ - 8,99 USD. Ціни змінюються, тому довіряйте сторінці, а не цьому абзацу.

Applet 1: скорочення посилань через IFTTT із RSS-стрічки

Найпростіший корисний applet перетворює кожен новий запис у блозі на коротке посилання з тегами, тож посилання вже існує, коли ви ним ділитеся. Він працює на Pro.

Перш ніж відкривати IFTTT, підготуйте в Elido три речі. Створіть ключ у розділі API keys на dashboard; він починається з elido_ і показується лише один раз. Скопіюйте ID workspace з URL dashboard. Потім один раз виконайте GET /v1/workspaces/{workspace_id}/domains і запишіть id та hostname домену, на якому мають розміщуватися посилання.

В IFTTT виберіть RSS Feed як сервіс "If This" із trigger 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 двічі надішле той самий запис, Elido протягом 24 годин повторно поверне оригінальну відповідь, а не створить дублікат посилання, оскільки ключем є просто URL запису.

Однак ця action працює без очікування відповіді. На сторінці action Make a web request IFTTT не зазначено ingredients відповіді, тому новий slug не потрапляє до наступного кроку. Посилання існує в Elido, має тег rss, і ви копіюєте його звідти. Для багатьох цього достатньо. Якщо ви хочете автоматично публікувати посилання десь іще, читайте далі.

Applet 2: читання slug через query і filter code

Pro+ змінює картину. Make a web request with JSON response від IFTTT - це query, а не action, і він повертає два ingredients: Status Code та Response Body. Filter code може розібрати це тіло, витягнути з нього slug і записати готовий короткий URL у наступну action applet, перш ніж IFTTT її виконає.

Створіть applet із тим самим RSS trigger. Додайте query із тією самою URL-адресою, заголовками й тілом, що й вище. Потім додайте action, наприклад Notifications, і відкрийте редактор 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,
  );
}

Важливі дві деталі. Elido відповідає 201 на успішне створення, а не 200, тому перевіряйте саме це. Також відповідь на створення не містить поля повного URL: ви отримуєте id, slug, destination_url, domain_id і часові мітки. Ви самостійно додаєте hostname свого домену до slug, тому я радила записати його заздалегідь. Наведені вище шляхи ingredients задокументовано на сторінці query IFTTT; автодоповнення редактора показує ті самі назви, тож довіряйте йому, якщо вони колись відрізнятимуться.

Замініть сповіщення на email або рядок у Sheets. Схема та сама. Будь-яка action, що приймає текст, може отримати коротке посилання.

Applet 3: сповіщення IFTTT Webhooks про короткі посилання з подій Elido

Зворотний напрямок починається в Elido. Вебхуки Elido спрацьовують на події workspace, і applet IFTTT може їх слухати. Це події життєвого циклу: link.created, link.updated, link.deleted, link.expired, link.cap_reached, а також кілька подій workspace та member. Події кліку немає, тому «надсилати смс на кожен клік» неможливо, та й насправді за реального обсягу вам цього не захотілося б.

Найкорисніша подія - link.cap_reached. Установіть max_clicks для посилання за допомогою PATCH /v1/workspaces/{workspace_id}/links/{link_id}, і Elido створить подію, щойно посилання досягне ліміту. Фонову перевірку виконують кожні кілька хвилин. Очікуйте сповіщення з невеликою затримкою.

Серед подій посилань форма вебхука на dashboard містить лише 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"}'

Назва події міститься в URL IFTTT, тому одна кінцева точка Elido відповідає одній події IFTTT. Зареєструйте другу кінцеву точку, якщо також хочете сповіщення про завершення терміну дії.

На боці IFTTT план визначає форма payload. Звичайний trigger Receive a web request відкриває лише value1, value2 і value3. Payload Elido - це оболонка з type, workspace_id, data і timestamp, тому ці три значення надходять порожніми. У Pro це все одно працює як простий сигнал: «посилання досягло ліміту, подивіться». Trigger JSON payload, зверніть увагу на /json/ у наведеній вище URL-адресі, передає все тіло як один ingredient. Розберіть його в Pro+:

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

Elido повторює невдалу доставку до трьох разів із паузами в кілька хвилин, а IFTTT відповідає 200 одразу після прийняття запиту. Помилки доставки тут трапляються рідко. Помилки applet виникають пізніше, всередині IFTTT, де Elido їх не бачить.

Хочете отримувати сповіщення про ліміт для наступного посилання на розіграш? Створіть безкоштовний workspace Elido, установіть ліміт кліків і налаштуйте наведений вище applet приблизно за десять хвилин.

Безпека: ключі, URL Maker і непідписані доставки

Обидва напрямки передають секрет IFTTT. Але ризики тут різні.

API-ключ Elido зберігається в полі заголовків applet. Будь-хто, хто може редагувати цей applet, може його прочитати. Створіть для нього окремий ключ із назвою для IFTTT, найнижчою роллю, яка все ще може створювати посилання, і датою завершення дії. Після відкликання він більше нічого не зламає. Значно гірше втратити ключ, спільний зі скриптами білінгу.

URL Maker серйозніша. Elido підписує кожну доставку: заголовок X-Webhook-Signature: v1=<hex> містить HMAC-SHA256 для часової мітки та необробленого тіла, і контрольований вами отримувач може відхилити підробки. У IFTTT немає кроку, який це перевіряє. Applet спрацьовує для кожного, хто знає URL, незалежно від підпису.

Тому я залишала б applet IFTTT, які живляться подіями Elido, для сповіщень і журналів. Підроблений запит може змусити ваш телефон подати сигнал. І нічого гіршого. Якщо подія має змінювати щось важливе, наприклад призупиняти кампанію або редагувати запис у CRM, надсилайте її отримувачу, який перевіряє підписи. У матеріалі про події вебхуків показано цю перевірку. n8n на власному сервері - одне з місць, де її можна запустити.

Коли IFTTT перестає бути правильним інструментом

IFTTT виграє завдяки trigger, яких немає в інших сервісах. Місцезнаходження, віджет телефона, датчик розумного дому, голосовий помічник - у IFTTT це нативні можливості, а всюди інде вони незручні. Якщо завдання звучить як "коли я прибуду на місце, створити коротке посилання на сьогоднішній вечір", це правильний інструмент, і я без вагань ним скористалася б.

Він перестає підходити у чотирьох випадках:

• Усе, що містить цикл. Applet обробляє одну подію trigger за раз. Скорочення 300 рядків з таблиці - це завдання для масового імпорту з Google Sheets, а не 300 запусків applet.
• Логіка retry. Коли API Elido відповідає 429 або 5xx, action просто завершується помилкою, а applet переходить далі. Вузол HTTP Request у n8n дає змогу повторити запит із очікуванням і спрямувати помилки туди, де їх буде видно.
• Обробка відповіді в межах бюджету. Читання slug коштує Pro+. Make і Zapier надають відповідь у кожному платному плані, а опис сценарію Zapier показує цей маршрут від початку до кінця.
• Розгалуження. Filter code може пропустити action, але справжня конструкція if/else між кількома сервісами належить Make або n8n.

Якщо ви взагалі пишете код, пропустіть візуальні інструменти й викликайте API з невеликого скрипту. У посібнику з лімітів швидкості та ідемпотентності описано правила retry, яких має дотримуватися будь-який викликач, зокрема IFTTT. Повний список кінцевих точок наведено в API та SDK Elido.

Прочитайте основний матеріал → короткий посібник з API та SDK скорочувача URL

На блозі також

• Автоматизація коротких посилань за допомогою Make та IFTTT - порівняння обох платформ в одному матеріалі.
• Скорочувач URL n8n - вузол HTTP Request із retry та ідемпотентністю.
• Автоматизація скорочення URL у Zapier - розміщений у хмарі маршрут із даними відповіді в кожному платному плані.
• Вебхуки для подій посилань - payload, перевірка підписів і retry.
• Як скоротити URL на iPhone - ручний спосіб, коли applet є зайвим.
• Сценарії скорочення URL у Make.com - багатоетапні процеси з routers, обробниками помилок і витратами кредитів.