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