Скорочувач 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 згенерує його; додайте його, якщо потрібна власна кінцева частина посилання. В документації HTTP-застосунку Make перелічено інші параметри, зокрема тайм-аути та пагінацію за курсором для спискових запитів.

Сценарій перший: скорочення 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 є надійна угода щодо назв.

Вставляєте 3 000 рядків одразу? Не пропускайте їх через Make по одному. Для цього призначений масовий імпорт із Google Sheets, який узагалі не коштує кредитів.

Сценарій другий: новий допис у блозі для планувальника соцмереж

Другий сценарій перетворює стрічку на заплановані дописи. RSS, Watch RSS feed items, перевіряє стрічку вашого блогу за розкладом. HTTP-модуль скорочує посилання елемента, передаючи заголовок допису в title і тег на кшталт rss. Третій модуль - дія create-post вашого планувальника, наприклад Buffer, із заголовком елемента та короткою URL-адресою як текстом.

Тут я люблю додавати маршрутизатор. Одна гілка веде до планувальника, інша надсилає те саме коротке посилання в канал Slack, щоб команда побачила його до публікації. Обидві гілки повторно використовують одне посилання з HTTP-модуля, тому ви платите за один виклик створення на елемент, а не за два.

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

Платите людині, щоб вона щовівторка вставляла посилання в планувальник? Створіть безкоштовний робочий простір Elido і під'єднайте цей сценарій стрічки за час, потрібний для читання наступного розділу.

Сценарій третій: вебхук 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 у налаштуваннях сценарію. У посібнику з обробника помилок Retry описано параметри спроби та інтервалу. Elido надсилає Retry-After під час перевищення ліміту швидкості, а відтворення за ключем гарантує, що повторне створення не створить дубліката.
• 400, 401, 403, 409: не повторюйте спробу. Код 400 означає відсутній domain_id або тіло у форматі форми, 401 - проблему з ключем, 403 - неправильний ідентифікатор робочого простору, а 409 - що власний slug уже зайнятий. Спрямуйте ці помилки до Resume with a fallback value або до Skip із електронним листом відповідальному за таблицю.

Кредити - інша половина питання. Відколи Make змінив одиниці білінгу, кожен запуск модуля коштує один кредит на пакет, а тригер опитування коштує один кредит за кожну перевірку, навіть якщо нічого не знаходить, як пояснюється в довідці з операцій Make. Саме ця плата за простій завдає найбільше клопоту:

Безкоштовний план Make надає 1 000 кредитів на місяць (перевірено у вересні 2026 року). Спостерігач Sheets із перевіркою кожні 15 хвилин витрачає майже втричі більше лише на перевірки. Збільште інтервал до години. Ще краще - використовуйте тригер вебхука всюди, де вихідний застосунок його пропонує.

Чи справді Make є правильним місцем для цього? Для кількох потоків, якими керують маркетологи, я вважаю, що так. Коли ви почнете створювати тисячі посилань на день, короткий скрипт на базі API та SDK Elido буде дешевшим і простішим для налагодження, а вебхуки Elido покриють push-частину. У посібнику з лімітів швидкості та ідемпотентності пояснюється 24-годинне вікно відтворення, яке використовується в усьому матеріалі.

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

Пов'язані матеріали в блозі

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