Skip to content
Пошук

Посібник для розробників

Створіть власний інструмент автоматизації нарощування посилань за допомогою BlogDrip API

Підключіть Ваше програмне забезпечення безпосередньо до BlogDrip та автоматизуйте оформлення замовлень гостьових постів. Побудуйте індивідуальні SEO-воркфлоу, інтегруйте існуючі додатки й ефективніше керуйте операціями з нарощування посилань.

Чому автоматизація

Навіщо створювати власний інструмент автоматизації нарощування посилань

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

Інтеграція через API знімає з Вашої команди повторювану механічну роботу й переводить її в код. Ваше існуюче програмне забезпечення — CRM, інструмент управління кампаніями або кастомна панель, в якій уже працює команда — спілкується з маркетплейсом напряму. Оператори лишаються сконцентрованими на стратегії, брифах і контролі якості замість ручного введення замовлень.

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

SEO team automating repetitive link building tasks

Що можна створити

Що можна побудувати з BlogDrip API

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

  • Індивідуальна панель для гостьових постів

    Внутрішній додаток, що підключається до BlogDrip і подає підтримувані замовлення гостьових постів через інтерфейс, яким керує Ваша команда.

  • Система управління для SEO‑агенції

    Оформлення гостьових постів інтегровано в існуючий робочий процес агенції, щоб менеджери кампаній не виходили зі звичної системи.

  • Автоматична подача замовлень

    Запити API створюють підтримувані замовлення гостьових постів пачками, без ручного введення даних для кожного замовлення.

  • Управління кампаніями клієнтів

    Підключіть внутрішні записи клієнтів і кампаній до процесів оформлення замовлень у BlogDrip — єдине джерело правди про те, хто що купує.

  • Автоматизація робочих процесів

    Тригерте підтримувані операції API з внутрішніх бізнес-процесів — затвердження, запуск кампаній, заплановані хвилі кампаній.

  • Звітність і моніторинг

    Витягайте інформацію про замовлення в кастомні інструменти звітності, де це підтримується. Обмежуйте звіти тим, що фактично відкриває API, замість припускати повну реальну видимість.

Архітектура

Приклад архітектури автоматизації

Коректна інтеграція розділяє обов'язки між чотирма шарами.

На верхньому рівні — зовнішній додаток автоматизації: кастомна панель, ПЗ для SEO‑агенції, внутрішній CRM або система управління кампаніями. Тут Ваша команда працює щоденно.

Під ним — бекенд Вашого додатка. Його обов'язки — те, що будь-яка інтеграція має виконувати правильно: безпечно зберігати `x-client-id` та `x-client-secret`, перевіряти вхідні дані ще до надсилання в BlogDrip, готувати й відправляти API‑запити, обробляти відповіді `{ data, pagination }`, логувати операційні події та безпечно керувати повторними спробами, щоб тимчасовий збій мережі не перетворився на дубльоване оплачуване замовлення.

Звідти запити потрапляють до BlogDrip Advertiser API — публічної, версіонованої поверхні під `/api/public/*`, що надає підтримувану функціональність оформлення замовлень гостьових постів.

API спрямовує замовлення в маркетплейс BlogDrip — понад 275,000+ сайтів у загальному інвентарі — а далі в відповідні процеси обробки замовлень і публікації. Залежно від обраного сайту публікація може виконуватися вручну на боці видавця або автоматично через WordPress plugin чи Agency API. Не кожен сайт у маркетплейсі підтримує Instant Publishing, тож Ваша інтеграція має розглядати час публікації як залежний від робочого процесу, а не миттєвий.

Four-layer architecture connecting an automation application to BlogDrip

Створіть інструмент автоматизації — покроково

Вісім кроків від визначення обсягу до моніторингу. Розглядайте їх як довідку, а не жорстку послідовність — багато з них виконуються паралельно.

  1. Визначте робочий процес автоматизації

    Визначте, які завдання мають бути автоматизовані, яка інформація потрібна Вашому додатку, коли слід подавати замовлення, як запобігати дублюванню замовлень, як обробляються помилки та як зберігаються дані кампаній. Конкретний приклад: агенція, що керує 20 клієнтами, кожен з яких має 3–5 активних кампаній, хоче, щоб нові кампанії автоматично створювали замовлення для короткого списку попередньо затверджених сайтів — але тільки після того, як людина затвердить бриф кампанії.

  2. Отримайте доступ до BlogDrip API

    Увійдіть у свій обліковий запис на app.blogdrip.com/settings і перейдіть до Мої налаштування → Доступ до API, щоб знайти Ваші облікові дані. Ви побачите два значення: `x-client-id` та `x-client-secret`. Секрет показується лише один раз при його видачі або ротації — негайно скопіюйте його в свій менеджер секретів. Для доступу необхідні мінімальні витрати на рахунку в розмірі €500 на місяць загалом — ручні замовлення та замовлення через API обидва враховуються. Доступ до API автоматично вимикається, якщо мінімум не виконано протягом місяця. €500 — це поріг витрат, а не окрема плата за підписку на API.

  3. Прочитайте документацію API

    Офіційна документація на app.blogdrip.com/api/public/docs/index.html описує точні кінцеві точки під простором імен `/api/public/*`, автентифікацію (пари заголовків, згадані вище), методи запитів, обов'язкові параметри, формати відповідей (ендпойнти списків повертають `{ data, pagination }` з 0‑базною пагінацією `?page=0`), помилки валідації (`{ message }`) та доступні операції оформлення замовлень. Розглядайте документацію як авторитетне джерело: якщо параметр не задокументований — не припускайте, що він існує.

  4. Побудуйте з'єднання з API

    Створіть бекенд додатка, який безпечно зберігає `x-client-id` та `x-client-secret` (змінні середовища, менеджер секретів — ніколи в frontend‑коді), надсилає автентифіковані запити з обома заголовками, парсить відповіді, обробляє помилки та веде структуровані логи для кожного вихідного виклику. Тримайте клієнт API маленьким і добре протестованим модулем, щоб решта Вашого додатка ніколи не зверталася до BlogDrip напряму.

  5. Реалізуйте автоматичне оформлення замовлень гостьових постів

    Підключіть внутрішній робочий процес до підтримуваних операцій оформлення в BlogDrip. Типовий потік: у Вашій системі створюється нова кампанія → обирається сайт (визначте його `marketSiteId` через ендпойнти маркетплейсу) → додаток готує потрібну інформацію для замовлення (заголовок, URL, опис, `categoryId`, `marketSiteId`, `campaignId`, опціонально `scheduleDate`, `linkNoFollow`) → бекенд перевіряє замовлення згідно з бізнес‑правилами → додаток надсилає замовлення через Advertiser API → відповідь зберігається у Вашій системі для трасування. Перевіряйте кожне поле відповідно до OpenAPI spec перед відправкою.

  6. Обробляйте помилки та дублікати замовлень

    Перевіряйте запити перед відправкою, запобігайтe випадковим дублюванням замовлень (ідемпотентний ключ або серверна перевірка на дублікати на Вашому боці — безпечний підхід), логуйтe кожну невдачу API з достатнім контекстом для подальшого дебагу, коректно обробляйте тимчасові проблеми з підключенням та дотримуйтеся задокументованих лімітів. Одне правило: ніколи не повторюйте автоматично неідемпотентний запит на створення замовлення без явного підтвердження від людини або системи — повторна відправка після успішного, але не отриманого Вами, відповіді створює подвійне списання.

  7. Протестуйте інтеграцію

    Тестуйте інтеграцію в sandbox, якщо він задокументований. Якщо sandbox недоступний — тестуйте у production обережно: ніколи не запускайте автоматизовані тести, які створюють реальні оплачувані замовлення без явного дозволу. Використовуйте спеціальну тестову кампанію з людиною в циклі перед першим автоматичним замовленням і обмежте автоматичні тести коротким allow‑list попередньо затверджених сайтів.

  8. Розгорніть і відслідковуйте

    Перенесіть облікові дані в продакшн‑менеджер секретів, додайте моніторинг для збоїв інтеграції та незвичних шаблонів подачі замовлень, відстежуйте результати подачі замовлень від початку до кінця, зберігайте операційні логи достатньо довго для дебагу інциденту віком у два тижні, моніторьте витрати рахунку, щоб не втратити доступ до API через зниження нижче €500 щомісяця, і стежте за changelog BlogDrip щодо оновлень API, які можуть вимагати підтримки інтеграції.

Шаблони інтеграції

Як виглядає коректна інтеграція

Авторитетне джерело для виконуваних прикладів — OpenAPI spec на app.blogdrip.com/api/public/openapi.json та читабельна документація на /api/public/docs. Специфікація — те, проти чого Ваш код має генеруватися або перевірятися — а не фрагмент для лендинга, який може застаріти.

На практиці чиста інтеграція зазвичай має однакову форму. Тонкий модуль клієнта API у вашій мові — по одній обгортці на потрібну операцію — керує механікою: ставить заголовки `x-client-id` і `x-client-secret` на кожен запит, серіалізує тіло запиту, десеріалізує конверт `{ data, pagination }` на ендпойнтах списків (0‑базна пагінація) і перетворює помилки (`{ message }`) у виключення, які бізнес‑логіка може коректно обробити. Кожна обгортка має принаймні один тест, що перевіряє задокументовану форму, тож зміна схеми проявиться як провалений тест до потрапляння в продакшн. Лише після стабілізації цього модуля підключайте його до решти додатка — тригери кампаній, черги замовлень, працівники повторних спроб, звітність.

Ця послідовність робить інтеграцію аудиторною: Ваш клієнт API — невелика, добре протестована поверхня; все інше спілкується з BlogDrip через неї.

Thin API-client module as a stable integration surface

Найкращі практики

Що робить інтеграцію API довговічною

Шаблони, що підтримують здоров'я автоматизованих систем довго після дня запуску.

  • Ідемпотентність за замовчуванням

    Розглядайте створення замовлення як дорогу й незворотну операцію. Видаляйте дублікати на Вашому боці перед відправкою запиту — ніколи після.

  • Гігієна облікових даних

    Облікові дані API мають зберігатися в менеджері секретів, розмежованому за середовищами. Ротуйте їх при звільненні працівника, а не лише після інциденту.

  • Структуроване логування

    Кожна пара запит + відповідь має ідентифікатор кореляції. Майбутній Ви, що дебагуватиме застаріле замовлення, подякує нинішньому.

  • Клієнти, що враховують ліміти

    Дотримуйтеся задокументованих лімітів. Клієнт, що коректно відступає, масштабується краще за того, що агресивно повторює запити.

  • Людина в ланцюгу

    Захистіть перший продакшн‑виклик людським затвердженням. Розширюйте автоматизацію лише після того, як інтеграція доведе стабільність.

  • Моніторинг витрат

    Сповіщайте, коли місячні витрати рахунку наближаються до або опускаються нижче €500. Втрата доступу до API посеред кампанії болюча.

Часті запитання

Для кого призначений BlogDrip API?

Облікові записи рекламодавців, які хочуть підключити власне програмне забезпечення — кастомну панель, платформу для SEO‑агенції, внутрішній CRM — до робочого процесу оформлення гостьових постів у BlogDrip. Типові користувачі — агенції, що керують кампаніями в обсязі, внутрішні SEO‑команди, які інтегруються у наявний стек, та розробники, що створюють операційні інструменти для конкретного клієнта чи продукту.

Чи потрібно бути розробником, щоб користуватися API?

Щоб побудувати саму інтеграцію — так. API — це програмний інтерфейс, його використання вимагає написання коду або співпраці з розробником. Якщо Ви бажаєте отримати операційні переваги без роботи над інтеграцією, інтерфейс маркетплейсу забезпечує ту ж функціональність оформлення вручну.

Які вимоги для доступу?

Активний обліковий запис BlogDrip, який витрачає щонайменше €500 на місяць у сукупності — ручні та API‑замовлення обидва враховуються. Доступ до API автоматично деактивується, якщо витрати рахунку в певному місяці нижчі за мінімум. €500 — це поріг обсягу витрат, а не окрема плата за підписку на API.

Де знайти документацію API?

Офіційна документація API опублікована на app.blogdrip.com/api/public/docs/index.html, а машинно‑зчитувана OpenAPI specification доступна на app.blogdrip.com/api/public/openapi.json. Обидва джерела описують схему автентифікації, повний каталог ендпоїнтів під простором імен `/api/public/*`, форми запитів і відповідей, формат пагінації та помилки. Розглядайте їх як джерело істини для Вашої інтеграції.

Де знайти мої облікові дані API?

У Мої налаштування → Доступ до API на app.blogdrip.com/settings. Ви отримаєте `x-client-id` та `x-client-secret`; обидва передаються в кожному автентифікованому запиті як HTTP‑заголовки. Секрет показується лише один раз під час видачі або ротації — негайно скопіюйте його в менеджер секретів, оскільки пізніше його не можна буде відновити. Облікові дані прив'язані до облікового запису; ставтеся до них як до інших секретів і не зберігайте в системах контролю версій.

Як працює пагінація на ендпойнтах списків?

Ендпойнти списків повертають відповіді в конверті `{ data, pagination }` і використовують 0‑базну пагінацію — передайте `?page=0` для першої сторінки, `?page=1` для другої і так далі. Блок pagination у відповіді підкаже, чи є ще сторінки. Якщо Ви мігруєте з legacy інтерфейсу `/api/<path>`, форма відповіді не змінилася — змінився лише базовий шлях на `/api/public/*`.

Чи підтримує API webhooks?

Перевірте OpenAPI spec на app.blogdrip.com/api/public/openapi.json для актуального списку підтримуваних механізмів callback або нотифікацій подій. Якщо функція не вказана — не припускайте її наявність у інтеграції; опитування API за власним розкладом — безпечний запасний варіант.

Чи є sandbox-середовище?

Авторитетна відповідь міститься в поточній документації API. Якщо sandbox перелічено — використовуйте його для інтеграційного тестування. Якщо sandbox не вказано — не створюйте реальні оплачувані замовлення під час автоматизованого тестування без явного дозволу; замість цього використовуйте спеціальну тестову кампанію з людиною в циклі.

Чи можуть замовлення через API використовувати Instant Publishing?

Наявність Instant Publishing залежить від того, чи має вибраний сайт підтримку автоматизованої публікації (через BlogDrip WordPress plugin або підключення Agency API). Будь‑яке замовлення — через API або вручну — розміщене на відповідному сайті може скористатися автоматичною публікацією. Не всі сайти в маркетплейсі підтримують цю можливість, тож інтеграція має вважати час публікації залежним від сайту.

У чому різниця між Advertiser API та Agency API?

Advertiser API призначений для клієнтів, які хочуть автоматизувати оформлення гостьових постів із власного ПЗ. Agency API — для зовнішніх агенцій, платформ для нарощування посилань і мереж видавців, які хочуть підключити власний інвентар до BlogDrip і автоматизувати підтримуване виконання. Обидва API автономні — використання одного не вимагає іншого.

Що станеться, якщо я повторю невдалий запит на створення замовлення?

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

Готові автоматизувати нарощування посилань?

Відкрийте документацію API, згенеруйте облікові дані та почніть розробку. Маркетплейс масштабується разом із Вашою автоматизацією — а не навпаки.