Свои домены для API и вебхуков
TLS, свой hostname и DNS рядом с маршрутами шлюза: публичные API, стабильные URL вебхуков и коллбеки партнёров — без «чужого» адреса провайдера в интеграциях.
Обновлено: 2026-06-28
Кратко
Суть ответа
Свои домены для API и вебхуков. Домен подключается на уровне API-шлюза: маршрутизация функций и терминация TLS настраиваются в одном месте.
Когда подходит и когда нет
- Публичные API для клиентов
- Вебхуки, которые партнёры вносят в allowlist по hostname
На что обратить внимание
- Зашитые в SDK URL вендора мешают white-label и мультитенантности: каждая клиентская интеграция наследует hostname, который потом не переименовать.
- Ошибка TLS или устаревший CNAME дают неочевидные сбои у клиентов — и отлаживать их со стороны приложения мучительно.
Ситуация: нагрузка и где обычно ломается
Зачем свой домен, а не только URL провайдера
Клиентам и партнёрам проще доверять api.example.com, чем длинному адресу вендора: свой домен снижает риск фишинга и делает дефолты SDK чище.
В enterprise-сегменте часто требуют явного контроля DNS и сертификатов в документации к интеграции ещё до подписания договора.
Компромиссы
Где обычно ломается настройка домена
Зашитые в SDK URL вендора мешают white-label и мультитенантности: каждая клиентская интеграция наследует hostname, который потом не переименовать.
Ошибка TLS или устаревший CNAME дают неочевидные сбои у клиентов — и отлаживать их со стороны приложения мучительно.
Как Inquir помогает в этом сценарии
Как это стыкуется со шлюзом
Домен подключается на уровне API-шлюза: маршрутизация функций и терминация TLS настраиваются в одном месте.
Многие провайдеры вебхуков — Stripe, GitHub, Shopify, Slack — требуют указать конкретный hostname в своих настройках. Стабильный api.yourproduct.com проще поддерживать и аудировать, чем меняющийся URL, сгенерированный вендором.
Те же API-ключи и режимы auth на маршрут, что и на домене по умолчанию.
Что вы получаете на платформе
Настройка домена для API и вебхуков
DNS
Спланируйте владение зоной и TTL до окна переключения, чтобы сам переход прошёл скучно.
Сертификаты
Автоматизируйте продление везде, где это позволяют DNS и политика выпуска.
Несколько клиентов
См. мультитенантную маршрутизацию, если нужен отдельный хост на клиента при общих сертификатах.
Что сделать дальше, по шагам
Как привязать домен к шлюзу Inquir
Подтвердить домен
Добавьте DNS-записи по инструкции платформы — доступ к вашему кластеру не нужен.
Назначить маршруты
Привяжите пути или wildcard-шаблоны к нужным функциям.
Понаблюдать
После выхода в прод следите за ошибками TLS и всплесками 4xx отдельно от деплоя кода.
Пример кода
Сначала DNS, потом маршруты
Сначала докажите владение доменом через DNS, затем настраивайте прикладные маршруты — это разные шаги, которые ломаются по-разному.
{ "host": "api.example.com", "routes": [{ "path": "/v1/ingest", "functionId": "ingest" }] }
Когда подходит и когда нет
Когда нужны свои домены
Когда это уместно
- Публичные API для клиентов
- Вебхуки, которые партнёры вносят в allowlist по hostname
Когда лучше выбрать другое
- Только внутренние инструменты, где достаточно URL платформы
Вопросы и ответы
Вопросы и ответы
Доступен ли wildcard для клиентских API?
Зависит от вашего сценария и от того, как платформа выпускает сертификаты. Проверьте выпуск и продление wildcard в документации до того, как обещать это партнёрам.
Что видит клиент при ошибке DNS или TLS?
Обычно сбой рукопожатия или «не тот» маршрут. Срок действия сертификата и здоровье CNAME мониторьте отдельно от релизов приложения.
Зачем стабильный URL для вебхуков?
Партнёрам проще аудировать постоянный api.product.com, чем меняющийся дефолтный адрес провайдера.