Интеграция со сторонними сервисами / API

С любыми, у которых есть публичное API: складские и учётные системы, ERP, службы доставки, маркетплейсы, системы бронирования, аналитика, мессенджеры, сервисы документов. CRM, платёжные системы и уведомления вынесены в отдельные услуги — там свои настройки сверх просто API.

Одна интеграция с одним сервисом объёмом до 5 эндпоинтов: анализ документации, маппинг полей, разработка обмена, обработка ошибок с повторными попытками, логирование, тестирование на реальных данных и документация.

Эндпоинт — это один адрес API, с которым работает интеграция: например, список товаров, обновление остатка, создание заказа, статус заказа, отмена. Пять таких адресов закрывают большинство задач; если ваш сценарий требует больше — посчитаем дополнительным блоком.

Сначала проводим технический анализ: смотрим, есть ли API вообще, насколько оно доступно и стабильно. По результатам даём оценку — иногда оказывается, что выгоднее обмен файлами или через промежуточный сервис автоматизации.

Интеграция не сломается: запросы становятся в очередь и повторяются по расписанию, а вы получаете уведомление о проблеме. Когда сервис поднимается, накопленные данные доходят автоматически.

Да, двусторонняя синхронизация — дополнительная услуга: данные обновляются и у вас, и в сервисе, с правилами, чья версия главная при конфликте. В базе идёт односторонний обмен в нужном вам направлении.

Зависит от сервиса: если он поддерживает вебхуки — данные приходят мгновенно по событию. Если нет — настраиваем обмен по расписанию с интервалом под вашу задачу, с учётом лимитов API.

WordPress и WooCommerce, Shopify, кастомные сайты и веб-приложения. Для WordPress обычно оформляем интеграцию отдельным плагином — чтобы обновления темы или сайта её не задевали.

Доступ к API сервиса (ключи или тестовый аккаунт), ссылка на документацию, описание того, какие данные и в какую сторону должны ходить. Остальное — маппинг, логику, обработку ошибок — спроектируем мы.

Да, 2 раунда правок в течение 7 дней после сдачи. Логику обмена фиксируем до старта разработки, поэтому финальные правки обычно касаются деталей, а не архитектуры.