Сервис сокращения ссылок IFTTT: апплеты Webhooks для коротких ссылок Elido

Сервис сокращения ссылок IFTTT на базе Elido строится на универсальном сервисе Webhooks IFTTT, поскольку собственного сервиса Elido в IFTTT нет. Апплет отправляет POST /v1/workspaces/{workspace_id}/links с заголовком Authorization: Bearer elido_... и JSON-телом, содержащим domain_id и destination_url, после чего Elido создаёт ссылку. В обратную сторону вебхук Elido отправляет события ссылок на ваш личный URL IFTTT Webhooks, где они становятся триггерами апплетов. Для Webhooks нужен IFTTT Pro. Чтобы прочитать созданную ссылку обратно, нужен Pro+.

Вот как это выглядит на практике. С помощью IFTTT можно сокращать ссылки из любого доступного ему триггера и реагировать на события жизненного цикла ссылок. Но на дешёвом тарифе нельзя взять новую короткую ссылку и использовать её в том же апплете, что в первый же день удивляет большинство пользователей.

Это руководство разбирает IFTTT подробнее, чем наши рецепты Make и IFTTT, где обе платформы рассматриваются рядом. Впервые работаете с API Elido? В кратком руководстве по API и SDK сначала объясняются ключи, рабочие пространства и домены.

Что на самом деле представляет собой интеграция IFTTT

Это два вставленных URL, по одному для каждого направления, без приложения OAuth между ними. Сервис Webhooks IFTTT обеспечивает обе стороны. Его действие "Make a web request" вызывает API Elido. Его триггер "Receive a web request" слушает URL с вашим личным ключом Maker, и на этот URL можно направить endpoint вебхука Elido.

Доступное направление зависит от тарифа IFTTT. Вот что было указано на странице тарифов IFTTT, когда я проверяла её 21 сентября 2026 года:

Бесплатные аккаунты получают два апплета, но вообще не получают Webhooks, поэтому бесплатный аккаунт IFTTT не может взаимодействовать с Elido. На момент проверки Pro стоил 2,99 USD в месяц, а Pro+ - 8,99 USD. Цены меняются, поэтому доверяйте странице, а не этому абзацу.

Апплет 1: сокращение ссылок через IFTTT из RSS-ленты

Самый простой полезный апплет превращает каждый новый пост в блоге в короткую ссылку с тегами, так что к моменту публикации ссылка уже существует. Он работает на Pro.

До того как открыть IFTTT, подготовьте в Elido три вещи. Создайте ключ в разделе API keys дашборда: он начинается с elido_ и показывается только один раз. Скопируйте ID рабочего пространства из URL дашборда. Затем один раз выполните GET /v1/workspaces/{workspace_id}/domains и запишите id и hostname домена, на котором должны находиться ссылки.

В IFTTT выберите RSS Feed как сервис "If This", укажите триггер 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 поста.

Но это действие работает по принципу fire-and-forget. На странице действия Make a web request IFTTT не указаны ингредиенты ответа, поэтому новый slug не переходит на следующий шаг. Ссылка существует в Elido, помечена тегом rss, и скопировать её можно оттуда. Для многих этого достаточно. Если вы хотите автоматически публиковать ссылку где-то ещё, читайте дальше.

Апплет 2: чтение slug через query и filter code

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

Создайте апплет с тем же RSS-триггером. Добавьте query с теми же URL, заголовками и телом, что указаны выше. Затем добавьте действие, например 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 и временные метки. Имя хоста своего домена нужно самостоятельно объединить со slug, поэтому я и просила записать его заранее. Указанные выше пути к ингредиентам приведены на странице query IFTTT; автодополнение редактора показывает те же имена, так что при расхождении ориентируйтесь на него.

Замените уведомление письмом или строкой в Sheets. Схема остаётся той же. Любое действие, принимающее текст, может получить короткую ссылку.

Апплет 3: оповещения IFTTT Webhooks о коротких ссылках из событий Elido

Обратное направление начинается в Elido. Вебхуки Elido срабатывают на события рабочего пространства, и апплет IFTTT может их слушать. Это события жизненного цикла: link.created, link.updated, link.deleted, link.expired, link.cap_reached, а также несколько событий рабочего пространства и участников. События на каждый клик нет, поэтому отправлять себе сообщение о каждом клике невозможно, да и при реальном объёме вам этого не хотелось бы.

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

Среди событий ссылок форма вебхука в дашборде показывает только created, updated и deleted. Для link.cap_reached и link.expired зарегистрируйте endpoint через 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, поэтому один endpoint Elido соответствует одному событию IFTTT. Если нужны также оповещения об истечении срока действия, зарегистрируйте второй endpoint.

На стороне IFTTT тариф определяется формой payload. Обычный триггер Receive a web request открывает только value1, value2 и value3. Payload Elido представляет собой оболочку с полями type, workspace_id, data и timestamp, поэтому эти три значения приходят пустыми. На Pro это всё равно работает как простой сигнал: "ссылка достигла лимита, проверьте её". Триггер JSON payload, обратите внимание на /json/ в URL выше, передаёт всё тело одним ингредиентом. Разберите его на 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 сразу после принятия запроса. Сбои доставки здесь редки. Сбои апплета происходят позже, внутри IFTTT, где Elido их не видит.

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

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

В обоих направлениях IFTTT получает секрет. Но степень риска у них разная.

API-ключ Elido находится в поле заголовков апплета. Любой, кто может редактировать этот апплет, сможет его прочитать. Выделите для IFTTT отдельный ключ с минимальной ролью, позволяющей создавать ссылки, и сроком действия. После отзыва ключа ничего другого не сломается. Потеря ключа, которым вы пользуетесь в скриптах биллинга, была бы куда серьёзнее.

URL Maker важнее. Elido подписывает каждую доставку: заголовок X-Webhook-Signature: v1=<hex> содержит HMAC-SHA256 для временной метки и необработанного тела, а управляемый вами получатель может отклонять подделки. В IFTTT нет шага, который проверяет подпись. Апплет сработает у любого, кто знает URL, независимо от подписи.

Поэтому я бы ограничила апплеты IFTTT, которые получают события Elido, уведомлениями и логами. Поддельный запрос может заставить ваш телефон зазвонить. Не более того. Если событие должно изменить что-то важное, например приостановить кампанию или отредактировать запись CRM, отправляйте его получателю, который проверяет подписи. В материале о событиях вебхуков показана такая проверка. Self-hosted n8n - один из вариантов для её запуска.

Когда IFTTT перестаёт быть подходящим инструментом

IFTTT выигрывает благодаря триггерам, которых нет у других платформ. Геопозиция, виджет телефона, датчик умного дома, голосовой помощник - всё это нативно поддерживается там и неудобно в других местах. Если задача звучит как "когда я приеду на площадку, создай короткую ссылку на сегодня", это подходящий инструмент, и я бы выбрала его без колебаний.

В четырёх случаях он перестаёт подходить:

• Всё, где нужен цикл. Апплет обрабатывает одно событие триггера за раз. Для сокращения 300 строк из таблицы нужен массовый импорт из Google Sheets, а не 300 запусков апплета.
• Логика повторов. Когда API Elido отвечает 429 или 5xx, действие просто завершается с ошибкой, а апплет идёт дальше. Узел HTTP Request в n8n позволяет повторить запрос с ожиданием и направить ошибки туда, где их можно увидеть.
• Обработка ответа на доступном тарифе. Чтение slug обратно стоит Pro+. Make и Zapier возвращают ответ на любом платном тарифе, а в руководстве по Zapier этот путь разобран от начала до конца.
• Ветвление. Filter code может пропустить действие, но настоящее if/else между несколькими сервисами лучше реализовать в Make или n8n.

Если вы вообще пишете код, пропустите визуальные инструменты и вызывайте API из небольшого скрипта. В руководстве по лимитам запросов и идемпотентности описаны правила повторов для любого клиента, включая IFTTT. Полный список endpoint смотрите в разделе API и SDK Elido.

Читайте основной материал → краткое руководство по API и SDK сервиса сокращения ссылок

Другие материалы в блоге

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