White-label скорочувачі URL для агенцій

Агенції потрібно більше, ніж логотип на дашборді. Потрібна чиста стіна між клієнтами, спосіб для співробітників клієнта заходити, не бачачи один одного, DNS, який можна повторити для двадцятого клієнта, і відповідь на питання "хто надсилає рахунок?". Цей посібник охоплює цей операційний бік.

Загальне питання про те, що означає white-label і як його подають вендори, розглянуто в посібнику про white-label скорочувачі URL. Я не повторюю його тут. Усе про Elido нижче перевірено за кодом 2026-10-24, а де чогось немає, я так і кажу.

Один робочий простір на клієнта

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

В Elido будь-який авторизований користувач може створити робочий простір і стає його власником, тож кожен клієнтський робочий простір ви створюєте самі. Потім reseller API фіксує зв'язок. Ви реєструєте reseller-акаунт на батьківському робочому просторі через POST /v1/workspaces/{id}/reseller (назва компанії, контактний email, необов'язкові домен і конфігурація брендування). Клієнта прив'язуєте через POST /v1/workspaces/{id}/reseller/workspaces, передаючи workspace_id клієнта та внутрішню мітку label, якої клієнт ніколи не бачить. Є також ендпоінти списку й видалення.

Чітко розумійте, що це таке. Прив'язка фіксує асоціацію. Вона не створює робочий простір, не переносить білінг і не агрегує використання. Це реєстр того, які клієнтські робочі простори належать вашій агенції.

Ролі для вашої команди та співробітників клієнта

Кожен робочий простір має учасників з однією з чотирьох ролей: owner, admin, editor або viewer. Кожна роль відповідає набору дозволів, а API застосовує дозволи на кожному маршруті. Брендування та керування reseller мають окремі дозволи, тож editor не зможе випадково змінити брендування клієнта.

Розумний розподіл:

• Ви й ваш керівник акаунта: owner або admin у кожному клієнтському робочому просторі.
• Клієнтські маркетологи, що будують посилання: editor.
• Клієнтські стейкхолдери, які лише читають звіти: viewer.

Ви запрошуєте людей електронною поштою з робочого простору, а API-ключі прив'язані до робочого простору та ролі, тож ключ, який ви даєте розробнику клієнта, не сягає іншого клієнта. Єдиний вхід (SSO) і SCIM існують на рівні робочого простору, що важливо для корпоративних клієнтів; дивіться SCIM і SSO.

Онбординг одного клієнта

Щоразу виконуйте ту саму послідовність. Її можна автоматизувати, а шлях через дашборд ідентичний.

1. Реєстрація один раз, прив'язка на клієнта. Зареєструйте reseller-акаунт, потім створіть клієнтський робочий простір і прив'яжіть його:

curl -X POST https://api.elido.app/v1/workspaces/$AGENCY_WS/reseller/workspaces \
  -H "Authorization: Bearer $ELIDO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"workspace_id": 99201, "label": "Client: TechCorp EMEA"}'

2. Спрямуйте домен клієнта. У Settings додайте хостнейм. Дашборд поверне два записи для DNS-панелі клієнта:

_elido-verify.techcorp-emea.example.  TXT    "verify=<token>"
go.techcorp-emea.example.             CNAME  edge.elido.me.

Фоновий воркер перевіряє DNS кожні 30 секунд до 24 годин, а потім сертифікат випускається на перший запит. Для wildcard CNAME - це *.example.com, а TXT стоїть на батьківському. Посібник про власні домени охоплює записи CAA і поширення, а в документації це розділ про власні домени, починаючи з плану Starter.

3. Забрендуйте робочий простір. Один виклик задає назву, логотип, колір, ім'я відправника листів і хостнейм порталу:

curl -X PUT https://api.elido.app/v1/workspaces/99201/branding \
  -H "Authorization: Bearer $ELIDO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"brand_name":"TechCorp Links","primary_color":"#0a2463",
       "email_from_name":"TechCorp Links",
       "portal_hostname":"links.techcorp-emea.example","enabled":true}'

Ось підступ, який дивує агенції. Перевірка плану читає план робочого простору, який ви брендуєте, а не вашого батьківського. Клієнтський робочий простір на Free чи нижчому платному рівні отримує 402 Payment Required. Business - на кожен клієнтський робочий простір.

4. Запросіть клієнта. Додайте його співробітників як editor або viewer, а себе лишіть власником. Листи, які вони отримують, несуть вашу назву бренду, колір, логотип і відображуване ім'я відправника. Адреса відправлення досі належить Elido, про що я б сказав клієнтам заздалегідь.

Білінг: будьте чесні з клієнтами

Саме тут white-label перепродаж ламається, тож я дам повну картину, а не відповідь продавця.

Elido виставляє рахунки по робочих просторах. Reseller API не формує зведеного рахунку, оптової ставки чи виписки по клієнту. Тож ви купуєте план кожного клієнтського робочого простору або даєте клієнту підписатися самому, а свою націнку виставляєте рахунком поза продуктом. Якщо вам потрібен один рахунок на двадцять клієнтів, продукт цього поки не вміє. Я додав це в беклог впровадження, і краще, щоб ви знали зараз, ніж дізналися наприкінці місяця.

Два практичні наслідки. По-перше, ціноутворюйте послугу як керовану (налаштування, звітність, підтримка), а не як перепродане місце, бо витрати в розрізі позицій видно по кожному робочому простору. По-друге, прорахуйте вартість на клієнта зі сторінки цін для плану, який потрібен кожному. Брендування змушує брати Business для кожного клієнта, якого ви хочете забрендувати повністю, і це домінує в математиці більше, ніж обсяг кліків.

Звітність по клієнтах

Аналітика обмежена робочим простором, тож viewer бачить лише кліки цього клієнта. Через API ключ, прив'язаний до робочого простору, може запитувати аналітику цього робочого простору, а для більших вибірок є асинхронні задачі експорту CSV. Для щомісячного клієнтського звіту цього досить.

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

Клієнти з ЄС і обробка даних

Коли ви перепродаєте клієнтам з ЄС, вони - контролери, ви - процесор, а платформа - субпроцесор за статтею 28 GDPR. Ваш клієнтський контракт потребує DPA, що охоплює дані кліків як персональні дані й називає ваших субпроцесорів. Список субпроцесорів і умови DPA беріть зі сторінки довіри Elido, а не з цього блогу, бо вони змінюються. Обіцянок щодо розташування даних я тут не даю. Стаття про GDPR містить подробиці стаття за статтею, а стаття про розташування даних у ЄС охоплює те, що питає DPO.

Перенесення клієнтської бази

Перенесення клієнтів з іншого інструмента має три треки: посилання, DNS і комунікація.

Спершу експортуйте посилання кожного клієнта зі slug, призначенням, доменом і тегами та позначте посилання, надруковані на папері чи вбудовані там, де їх не відредагувати. Імпортуйте через POST /v1/workspaces/{id}/links/bulk до того, як чіпати DNS, і перевірте кілька редиректів. Знизьте TTL CNAME до 300 секунд щонайменше за 48 годин, переключайтеся в тиху годину й тримайте старий акаунт приблизно два тижні. Повідомте клієнтів за тиждень.

Історія кліків між інструментами не мігрує, тож експортуйте звіти для кожного клієнта до закриття старого акаунта. Плейбук міграції з Bitly містить специфіку Bitly.

Що показують інші інструменти щодо розділення клієнтів

Публічні сторінки цін мало кажуть про функції для агенцій. Прочитано 2026-10-24:

Джерела: Rebrandly, Short.io, Bitly і Dub, дата звернення 2026-10-24. Відсутність на сторінці цін не доводить відсутності в продукті, тож попросіть кожного вендора показати потік онбордингу клієнта в пробній версії.

Читайте також у блозі

• White-label скорочувачі URL: що насправді покриває ярлик
• Налаштуйте брендовані короткі посилання: оберіть домен і запустіться за вечір
• SCIM і SSO для маркетингових інструментів: що питає корпоративне IT
• Розташування даних у ЄС для маркетингових інструментів: що питає ваш DPO
• Міграція з Bitly: плейбук