Сокращатель URL в Make.com: три сценария коротких ссылок

Сокращатель URL в Make.com работает через один модуль: HTTP, Make a request. Он отправляет POST-запрос на https://api.elido.app/v1/workspaces/{workspace_id}/links с ключом API Bearer и телом JSON, содержащим domain_id и destination_url, а Elido отвечает slug новой ссылки. Объедините этот slug с именем хоста, и получите короткую ссылку. Вот и весь приём, и он работает на любом тарифе Make.

Люди, которые ищут «make short link module», обычно ожидают увидеть брендированную карточку Elido в списке модулей. Пока устанавливать нечего. Поэтому в этом руководстве используется собственное приложение HTTP от Make. Ниже вы найдёте сам запрос, три сценария, которые я действительно запускала бы, способ проверить подписанные вебхуки внутри Make и стоимость каждого сценария в кредитах.

Впервые работаете с REST API Elido? Начните с краткого руководства по API и SDK. В нём объясняются токены, рабочие пространства и домены, которые в этой статье считаются уже знакомыми.

Что Make предлагает для коротких ссылок Elido сегодня

Короткий ответ: приложение HTTP. В открытом репозитории Elido действительно есть исходный код пользовательского приложения Make с подключением, модулями создания, обновления, поиска и аналитики, а также триггерами событий ссылок. Но в общедоступный каталог приложений Make оно не включено. Чтобы загрузить его, пришлось бы добавить его в собственную учётную запись разработчика Make и самостоятельно поддерживать там.

Поэтому пока я бы его не использовала. Модуль HTTP обращается к любой конечной точке, позволяет задавать любые заголовки и переживает изменения с обеих сторон, поскольку это всего лишь запрос. Когда приложение появится в каталоге, описанные ниже сценарии можно будет перенести с теми же формами данных: оба пути обращаются к одним и тем же конечным точкам с одинаковыми телами и ключом API.

Здесь используются стандартные приложения Make: HTTP, Webhooks, JSON, Google Sheets, RSS и Slack. Если вы сравниваете платформы, в руководстве по сокращателю URL для n8n описано то же API в n8n. В руководстве по Zapier рассматривается Zapier.

Создание запроса короткой ссылки в Make

До первого сценария вам понадобятся три вещи: ключ API, идентификатор рабочего пространства и идентификатор домена.

Создайте ключ в дашборде Elido в разделе API keys. Он начинается с elido_ и показывается только один раз, поэтому сразу вставьте его в Make. В модуле HTTP выберите тип аутентификации API key и создайте учётные данные, которые помещают Bearer elido_... в заголовок с именем Authorization. Make сохранит их как повторно используемые учётные данные. Это гораздо удобнее, чем вставлять заголовок в каждый модуль.

Идентификатор рабочего пространства находится в URL дашборда. Чтобы получить идентификатор домена, один раз выполните пробный GET-запрос к /v1/workspaces/{workspace_id}/domains с помощью Run once: у каждого элемента есть id и hostname. Запишите оба значения.

Затем настройте Make a request следующим образом:

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

Ответ содержит запись ссылки: id, slug, destination_url, domain_id, tags и временные метки. Готового поля с полным URL нет, поэтому последующие модули формируют его как https://go.example.com/{{2.data.slug}}, используя имя хоста вашего домена. Не указывайте slug, и Elido создаст его автоматически; добавьте его, если нужна запоминающаяся конечная часть URL. В документации приложения HTTP Make перечислены остальные параметры, включая тайм-ауты и постраничную выдачу с курсором для запросов списков.

Сценарий 1: сокращение URL в строке Google Sheets

Большинство команд начинают с этого. Это также сценарий, который удивляет их счётом. В таблице планирования есть столбец url; каждая новая строка должна получить короткую ссылку в столбце D.

Цепочка состоит из трёх модулей. Google Sheets, Watch New Rows, срабатывает для каждой строки, добавленной после последней проверки. Приведённый выше HTTP-запрос подставляет ячейку url строки в destination_url. Затем Google Sheets, Update a Row, записывает https://go.example.com/{{2.data.slug}} обратно в ту же строку, используя переданный триггером номер строки.

Важны две детали. Поставьте между триггером и модулем HTTP фильтр, который останавливает строки с пустым url, поскольку пустые строки чаще всего становятся причиной ответов 400. И сохраняйте Idempotency-Key: если после тайм-аута Make повторит попытку для строки, тот же ключ воспроизведёт первую ссылку вместо создания дубликата. Нужны UTM-параметры в каждой ссылке? Сначала добавьте их в адрес назначения с помощью шага Set variable. В руководстве по отслеживанию UTM от начала до конца приведено соглашение об именовании, которое хорошо работает на практике.

Вставляете сразу 3000 строк? Не пропускайте их через Make по одной. Для этого предназначен массовый импорт из Google Sheets, который вообще не расходует кредиты.

Сценарий 2: новая запись в блоге и планировщик публикаций в соцсетях

Второй сценарий превращает ленту в запланированные публикации. RSS, Watch RSS feed items, проверяет ленту блога по расписанию. Модуль HTTP сокращает ссылку записи, подставляя заголовок публикации в title и тег вроде rss. Третий модуль - действие планировщика по созданию публикации (например, Buffer), которому в качестве текста передаются заголовок записи и короткий URL.

Мне нравится добавлять сюда маршрутизатор. Одна ветка ведёт в планировщик, другая отправляет ту же короткую ссылку в канал Slack, чтобы команда увидела её до публикации. Обе ветки повторно используют одну ссылку из модуля HTTP, поэтому вы платите за один вызов создания на элемент, а не за два.

Одна вещь, которую я поняла не самым приятным способом: ленты публикуют записи повторно. CMS, которая меняет дату старой записи, может вернуть её в ленту, и без Idempotency-Key сценарий создаст новую ссылку для записи, которой вы поделились несколько месяцев назад. Хеширование URL записи, как в конфигурации выше, означает, что повтор в течение 24 часов воспроизводит исходный ответ. Для более старых повторов нужна проверка в хранилище данных по ключу URL.

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

Сценарий 3: вебхук link.created в Slack

Первые два сценария отправляют ссылки в Elido. Этот - слушает. Когда кто-либо в рабочем пространстве создаёт ссылку из дашборда, через API или в другом сценарии, Make публикует её в канале аудита.

Начните с Webhooks, Custom webhook и скопируйте URL, который выдаст Make. В Elido откройте Webhooks, добавьте конечную точку с этим URL и отметьте link.created. Секрет показывается один раз. Сохраните его.

В расширенных настройках Custom webhook включите JSON pass through и Get request headers. Вам нужно исходное тело без изменений, поскольку Elido подписывает timestamp.raw_body с помощью HMAC-SHA256 и отправляет результат в X-Webhook-Signature: v1=<hex>, а метку времени - в X-Webhook-Timestamp. Повторно сериализованное тело не совпадёт. Функция sha256 в Make принимает аргумент-ключ и возвращает HMAC, поэтому фильтр может выполнить проверку:

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

После фильтра JSON, Parse JSON превращает исходный текст в поля, а Slack, Create a Message публикует {{3.data.slug}} и {{3.data.destination_url}}. Полезная нагрузка содержит type, workspace_id, data (запись ссылки) и timestamp.

События клика нет, и со стороны Elido это сделано намеренно: вебхуки охватывают жизненный цикл ссылок и рабочих пространств, но не трафик. Для показателей кликов лучше всего подходит ежедневный плановый сценарий. В документации приложения Webhooks Make объясняется очередь за Custom webhook, а в нашем материале о вебхуках для событий ссылок подробнее рассматриваются полезные нагрузки и повторы доставки.

Обработка ошибок и стоимость кредитов в Make

По умолчанию модуль HTTP Make считает ошибкой любой ответ 4xx или 5xx, что нам и нужно. Дальнейшие действия зависят от обработчика ошибок, прикреплённого к модулю.

Настройте обработчик по коду состояния:

• 429 или 5xx: добавьте Retry. Он помещает неудачный пакет в незавершённое выполнение и повторяет попытку позже, поэтому сначала включите Store incomplete executions в настройках сценария. В руководстве Make по обработчику ошибок Retry описаны параметры попыток и интервала. Elido отправляет Retry-After при ограничении частоты, а воспроизведение по ключу гарантирует, что повторное создание не создаст дубликат.
• 400, 401, 403, 409: не повторяйте запрос. Ответ 400 означает отсутствие domain_id или тело в формате формы, 401 - проблему с ключом, 403 - неверный идентификатор рабочего пространства, а 409 - занятый пользовательский slug. Направьте эти случаи в Resume with a fallback value или в Skip с отправкой письма ответственному за таблицу.

Кредиты - вторая часть расчёта. После перехода Make на расчётные единицы каждый запуск модуля стоит один кредит на пакет, а триггер с опросом стоит один кредит за проверку, даже если ничего не нашёл, как объясняется в справочнике операций Make. Именно эта стоимость простоя становится проблемой:

Бесплатный тариф Make даёт 1000 кредитов в месяц (проверено в сентябре 2026 года). Наблюдатель Sheets с интервалом 15 минут расходует почти втрое больше только на проверки. Увеличьте интервал до часа. Ещё лучше - используйте триггер-вебхук, если исходное приложение его поддерживает.

Подходит ли Make для этого вообще? Для нескольких потоков, которыми управляют маркетологи, да, я так считаю. Когда вы создаёте тысячи ссылок в день, короткий скрипт для API и SDK Elido дешевле и его проще отлаживать, а вебхуки Elido закрывают сценарии с отправкой событий. В руководстве по ограничениям частоты и идемпотентности URL объясняется используемое здесь 24-часовое окно воспроизведения.

Прочитайте краеугольный материал → краткое руководство по API и SDK сокращателя URL

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

• Сокращатель URL для n8n: узел HTTP Request или пользовательский узел - то же API в n8n, в облаке или на собственном хостинге.
• Автоматизация сокращения URL в Zapier - путь Zapier для тех же задач.
• Вебхуки для событий ссылок - полезные нагрузки, подписи и поведение при повторной доставке.
• Бот Slack для сокращения ссылок и оповещений - когда стороне Slack нужно отдельное приложение.
• Апплеты сокращателя URL для IFTTT - те же задачи через триггеры телефона и ленты на вебхуках IFTTT.