Для розробників

Хостинг, яким ви можете керувати з коду

Zinn Digital® — це платформа на основі підходу API-first. Той самий рушійний API, який забезпечує роботу нашої панелі керування, отримуєте й ви — з підтримкою версійності, орієнтований на специфікацію та на 100% задокументований під час збирання, зі створеними SDK, CLI, провайдером Terraform, підписаними вебхуками та сервером MCP на додачу. Хоч би чим ви користувалися для роботи — терміналом, конвеєром, файлом стану чи ШІ-агентом, — платформа реагує на це.

Кінцева точка API, яка доставляє підписані події кільком підписаним слухачам.
  • 700 000+сайтів на хостингу по всьому світу
  • 1Специфікація OpenAPI, з якої генерується кожен інструмент
  • 4клієнтські SDK — TypeScript, Python, PHP, Go
  • OAuth 2.1обмежений, відкличний доступ агента ШІ

Один API. Кожна поверхня спирається на нього.

Більшість хостингів додають API до панелі керування вже постфактум, і це помітно — половина функцій панелі так ніколи й не виходить назовні. Ми побудували все навпаки. Панель приладів, консоль адміністратора, CLI, провайдер Terraform, сервер MCP та ваші власні інтеграції використовують один і той самий API рушія. Якщо ви можете зробити це в панелі, ви можете зробити це і в коді.

Спочатку специфікація, а не документування згодом

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

Згенеровано, ніколи не підтримується вручну

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

Версіоновано з політикою застарівання

Кінцеві точки розташовані під /v1 із опублікованою політикою припинення підтримки та журналом змін. Вас письмово попереджають перед тим, як щось зміниться, а не змушують дізнаватися про це через невдалу збірку.

Протестовано за контрактом у CI

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

Автентифікація, визначення меж та підводні камені масштабування

Два способи доступу, за якими стоїть єдиний принцип. Хоч би який із них ви використовували, застосовуються ті самі перевірки дозволів і та сама ізоляція на рівні бази даних.

Ключі API, за організацією

Ключі мають вигляд zdk_<mode>_<prefix>_<secret>. Зберігається лише хеш SHA-256 секретної частини — ми не зможемо показати вам ключ знову після створення, як і будь-хто, хто отримає доступ до нашої бази даних. Ключі мають області дії, можуть бути відкликані та видаються для організації, а не для окремої особи.

Робочий і тестовий режими, відокремлені один від одного

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

OIDC для людей

Сеанси користувачів автентифікуються за допомогою виданих Keycloak токенів JWT, перевірених за відкритим ключем realm, і розпізнаються як той самий об'єкт Principal, що й ключ API. Кінцеві точки обмежуються деталізованими ключами дозволів, такими як sites.create або apikeys.manage, які перевіряються для кожної організації окремо — дозвіл в одній організації не надає доступу до окремої, не пов'язаної організації, хоча він застосовується до організацій, вкладених у неї.

Безпека на рівні рядків знизу

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

Створено для машин, а не лише для демонстрацій

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

Одна деталь, про яку варто згадати, оскільки вона визначає особливості масової роботи: помилка 409 у разі дублювання домену відповідає на запитання «чи розміщено це ім'я хосту тут?» для будь-якого орендаря, що є оракулом перелічення та реальним ризиком деанонімізації для Footprint-Free. Обмеження швидкості створення сайтів було б невиправдано простим рішенням і повністю порушило б роботу продукту для масового надання ресурсів. Натомість ліміт встановлюється лише для відхилених спроб створення дублікатів доменів для кожного принципала. Успішні створення ніколи не зараховуються до цього ліміту — тому ви можете надавати ресурси масово протягом усього дня, а спроби зондування припиняються майже миттєво.

  • Уніфікована структура відповіді в разі будь-якої помилки: код, зрозуміле повідомлення, необов'язкові відомості на рівні полів та request_id, який ви можете повідомити службі підтримки. Помилки валідації повертають код 422 із зазначенням некоректних полів.
  • Ключі ідемпотентності для POST із записом відтворення, який зберігається під час фіксації (commit), а не в процесі виконання, — тому повторна спроба ніколи не зможе відтворити кешовану відповідь 201, що вказує на рядок, який ніколи не було зафіксовано. Неуспішний запит негайно знімає активне блокування, тому помилка 422 не блокує вашу виправлену повторну спробу.
  • Курсорна пагінація як набір ключів поверх UUIDv7 — стабільна при одночасних записах, без зміщення сторінок при вставці рядків під час сканування.
  • RateLimit-Remaining у відповідях, щоб згенерований клієнт міг розумно знижувати частоту запитів, а не вгадувати.
  • Ресурси за межами області доступу повертають 404 замість 403 — код 403 підтвердив би існування ресурсу. Фільтрація за організацією поза вашою областю доступу повертає порожню сторінку з тієї ж причини.
  • Створення сайту є реєстрацією, а не підготовкою: POST /v1/sites повертає 201 зі статусом pending і ніколи не блокує збірку. Подія записується до транзакційного outbox у тій самій транзакції, що й рядок, тому сайт існує тоді й лише тоді, коли гарантовано буде надіслано запит на його підготовку.

SDK, CLI та провайдер Terraform

Три споживачі однієї специфікації для трьох різних способів роботи.

Клієнтські SDK

Згенеровано для TypeScript, Python, PHP та Go з відстеженням специфікації, тому нова кінцева точка з'являється у вашій мові без очікування написаної вручну обгортки.

Zinnector®, CLI

Створіть структуру сайту WordPress, запустіть його локально, маючи встановленим лише Node, та розгорніть його. Zinnector® попередньо перевіряє ваш проєкт на відповідність слоту, у який ви збираєтеся його розгорнути — версія PHP, диск, кількість файлів — і попереджає до того, як ви відправите зміни, а не після. Він також входить у систему, показує список сайтів, розгортає, керує доменами та DNS, зчитує поштові служби, створює резервні копії, виконує дозволені команди WP-CLI, відстежує логи в реальному часі та запускає масові операції. Безкоштовно, за ліцензією MIT та створено на базі цього ж публічного API.

Постачальник Terraform

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

Інтерактивний довідник

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

Вебхуки, які витримують збій вашої кінцевої точки

В основі платформи лежить надійна магістраль подій: кожна зміна стану атомарно зі зміною в базі даних записує подію в транзакційний outbox у Postgres, а реле публікує її в NATS JetStream. Події є типізованими та версіованими — site.deployed, order.paid, invoice.overdue, backup.completed, abuse.flagged, trial.ending та інші.

Підпишіться на те, що для вас важливо

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

Підписано за допомогою HMAC

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

Повторено спробу із затримкою та зафіксовано в журналі

Невдалі доставки повторюються з поступовим збільшенням інтервалу, і кожна спроба записується як WebhookDelivery. Ви можете перевіряти та повторювати доставки з панелі керування замість того, щоб писати на електронну пошту служби підтримки із запитанням про те, що саме ми надіслали.

Принаймні один раз, тому усувайте дублікати за id

Конвеєр навмисно реалізовано за принципом «щонайменше один раз» (at-least-once), замість вдавати, що це «точно один раз» (exactly-once). У реле, яке аварійно вимикається під час публікації, спливає термін оренди клейму, і його події публікуються повторно. Виконуйте дедуплікацію за envelope id, і ваш споживач буде коректним за побудовою.

Розміщення коду на сайті

API — це лише половина історії розробника. Інша половина — це випуск продукту.

  • Підключіть GitHub, GitLab або Bitbucket через OAuth, при цьому ключі розгортання зберігаються в сховищі облікових даних — а не у файлі конфігурації.
  • Push запускає конвеєр збирання та розгортання з зіставленням гілок і середовищ (main для production, staging для staging) та кроками збирання для кожного стека для composer і npm.
  • Поверніться до попереднього випуску, якщо розгортання пішло не так.
  • Тестове клонування та публікація наживо, щоб зміни перевірялися в реальних умовах до того, як вони стануть доступними для відвідувачів.
  • SFTP для кожного сайту з ізоляцією CageFS, завдяки чому кожен орендар бачить лише власні файли, а також ізольована (jailed) оболонка SSH на спільній платформі.
  • wp-cli з термінала панелі та через SSH.
  • VS Code у браузері через code-server — повнофункціональний редактор із git, що редагує файли сайту напряму.
  • Версія PHP для кожного сайту, редаговані налаштування PHP, розширення для кожного сайту, змінні середовища та справжній cron поряд із WP-cron.

Чотири способи роботи над сайтом

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

Вебредактор

VS Code у браузері, відкритий зі сторінки сайту на панелі керування, редагує справжні файли цього сайту з вбудованим git і всім редактором у тій самій ізоляції CageFS, що й ваш доступ через SFTP. Він редагує РОБОЧИЙ сайт — проміжної тестової копії немає, тому збережений вами файл стає загальнодоступним у момент запису, хоча статичний файл може продовжувати надаватися з кешу CDN до чотирьох годин.

Zinnector®, CLI

Безкоштовно, за ліцензією MIT і побудовано на цьому ж публічному API. Створіть структуру сайту WordPress, запустіть його на власному комп'ютері, виконайте попередню перевірку для слота, в який ви збираєтеся його розгорнути — версія PHP, диск, кількість файлів — і розгорніть. Потрібен Node 24 або новішої версії.

Сервер MCP

Єдиний каталог інструментів, завдяки якому клієнт штучного інтелекту, яким ви вже користуєтеся, може працювати з вашими сайтами через той самий API і ті самі дозволи, які використовує панель керування. Той самий сервер, до якого підключається ваш власний клієнт, підключено й до веб-редактора. Лише для читання, доки ви не вкажете інше.

Доступ розробника для кожного сайту

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

І той самий API, який може використовувати ваш ШІ-агент

Ми надаємо платформу як хостинговий MCP-сервер: тонкий адаптер протоколу поверх API рушія, який повторно використовує той самий каталог дій, RBAC і журнал аудиту. Підключіть Claude Code, Cursor, ChatGPT, Claude Desktop або будь-який сумісний із MCP клієнт один раз, і кожна нова можливість, яку ми додаємо до API, стане автоматично доступною для нього.

Агент отримує три речі: Інструменти (ті самі кінцеві точки API, без паралельної логіки, яка могла б розбігатися), Ресурси (доступні лише для читання дані про стан сайту, конфігурацію, останні журнали, показники, час безвідмовної роботи та статті бази знань, тож він проводить діагностику на основі реальних даних перед початком дій) і Підказки (опубліковані шаблони робочих процесів, такі як «діагностувати цей сайт» або «підготувати міграцію»).

Безпека базується на тих самих принципах, що й автентифікація: OAuth 2.1, токени, прив'язані до вашої організації, та дозволи RBAC із застосуванням безпеки на рівні рядків, обмежені за областю дії та відкличні для кожного інструмента, а також пісочниця, відокремлена від робочого середовища. Деструктивні дії — видалення, призупинення, виставлення рахунків, значні витрати — вимагають явного підтвердження або політики схвалення людиною. Ліміти частоти запитів і ліміти витрат обмежують платні дії, ініційовані ШІ, а кожен виклик MCP фіксується в журналі аудиту із зазначенням ідентифікатора, інструмента, аргументів і результату.

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

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

Чи є загальнодоступний API тим самим, який використовує панель керування?

Так — це той самий API рушія, опублікований і захищений. Панель керування, консоль адміністратора, CLI, провайдер Terraform, сервер MCP та вебхуки є споживачами одного інтерфейсу, саме тому API не відстає від панелі.

Чи можу я протестувати інтеграцію, не витрачаючи грошей і не створюючи реальних серверів?

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

Як запобігти створенню дубліката під час повторної спроби?

Надсилайте Idempotency-Key у своєму POST-запиті. Запис повтору створюється під час фіксації (commit), а не лінійно (inline), тому повторна спроба ніколи не відтворить кешований успіх для рядка, який насправді не було зафіксовано, а запит, що зазнав помилки, негайно звільняє своє блокування, тож ваша виправлена повторна спроба не затримується. Доставка вебхуків за замовчуванням здійснюється за принципом «щонайменше один раз» (at-least-once) — виконуйте дедуплікацію за envelope id на своєму боці.

Чи можу я надати одному ключу API доступ до всіх організацій моїх клієнтів?

Не сьогодні. Ключі API видаються для кожної організації окремо, тому інтеграція, яка охоплює кілька клієнтських організацій, має ключ для кожної з них. Дозволи також перевіряються для кожної організації для суб'єктів-користувачів: наявність sites.create в одній організації не надає доступу в окремій, не пов'язаній організації, хоча застосовується до організацій, вкладених у неї. Це зроблено навмисно — скомпрометований ключ обмежується власною організацією та підпорядкованими їй суборганізаціями, а не всією платформою.

Що насправді дозволяє вбудована роль «Розробник»?

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

Що станеться з моїми вебхуками, якщо моя кінцева точка вийде з ладу на одну годину?

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

Скільки коштує розпочати розробку за допомогою цього?

Почніть із 14-денного пробного періоду Footprint-Free хостингу без банківської картки — жодних платіжних даних, до 5 сайтів. Платні тарифи Footprint-Free починаються від $6/міс. за PBN 5. Кожен план передбачає 30-денну гарантію повернення коштів, безкоштовне перенесення та відсутність прив'язки до постачальника.

Прочитайте специфікацію, а потім будуйте відповідно до неї

API на основі специфікацій, згенеровані SDK, CLI, провайдер Terraform, підписані вебхуки та сервер MCP — на хостингу, який ми створили для понад 700 000 сайтів по всьому світу. Почніть із 14-денного пробного періоду без картки та платіжних даних.

Почати безкоштовно

Плагіни WordPress, з якими може працювати ваш штучний інтелект

Кожен із цих плагінів перетворює ваш сайт на WordPress на MCP-сервер, тож Claude, Cursor, VS Code та інші помічники зі штучним інтелектом можуть виконувати на ньому реальну роботу, увійшовши під вашим обліковим записом і з обмеженнями ваших прав доступу.

Уся документація з MCP та API для розробників →