H-Studio
Обсудить проект
API и интеграции — H-Studio
Услуга · API и интеграции

API и интеграции, когда «настроить модуль 1С»⁠ уже не справляется.

Integration architecture как инженерная дисциплина: REST/GraphQL API, webhooks, очереди, идемпотентность, retry-логика, журнал событий.

Формат
API design · Интеграции · Event-driven
Подходит для
SaaS · B2B-платформы · e-commerce · маркетплейсы
Старт
Integration-аудит или прямая разработка
Подход · не «модуль из маркетплейса»

Архитектура, которая не сломается при задержке или дубле события.

Не «подключим модуль из маркетплейса 1С-Битрикс» — а архитектура, которая не сломается, когда внешний сервис задержится, продублирует событие или поменяет ответ.

Senior-команда без джунов, открытые цены, от 200 000 ₽, 2–12 недель.

От 200 000 ₽, 2–12 недель. Senior-команда без джунов. Открытые цены.
01 · Сигналы, что интеграции стали ключевой задачей

Пять ситуаций, в которых задача попадает к нам.

У каждой ситуации — свой корень проблемы и свой формат работ. На первой встрече фиксируем стадию и предлагаем тариф под неё.

Scenario · 01

“«Нужно связать сайт или продукт с CRM, 1С и платежами»”

Заявки с сайта в AmoCRM или Битрикс24, заказы в 1С, оплата через ЮKassa, склад через «Мой Склад», уведомления через email/SMS/Telegram. Сейчас всё переносят руками или через костыли (Zapier, Albato, самописные скрипты, которые ломаются раз в неделю). Что мы делаем: integration-спринт — фиксируем источник истины для каждой сущности, проектируем синхронные и асинхронные паттерны, обработку ошибок и журнал, реализуем устойчивый интеграционный слой.

Scenario · 02

“«Наше собственное API стало хаотичным»”

Endpoints добавлялись по запросам, нет версионирования, нет нормальной документации, фронт и интеграторы угадывают контракты, breaking changes ломают партнёров. Команда тратит часы на ответы вида «как работает такой-то endpoint». Что мы делаем: API-аудит и redesign с правильными контрактами (OpenAPI), стратегией версионирования, единым форматом ошибок, согласованной пагинацией и фильтрацией, документацией, отражающей бизнес-смысл.

Scenario · 03

“«Нужно опубликовать API для партнёров»”

SaaS-продукт вырос, появились партнёры или клиенты, которым нужен программный доступ. Внутреннее API «как есть» отдавать нельзя — нужны авторизация, ключи, ограничения по скорости, версионирование, документация для разработчиков, sandbox-окружение, SLA. Что мы делаем: проектируем публичный API с ролевым доступом, систему API-ключей, лимиты, документацию, sandbox и onboarding для внешних разработчиков.

Scenario · 04

“«Внешние сервисы делают систему хрупкой»”

1С зависает на 30 секунд, CRM присылает один и тот же webhook дважды, платёжный провайдер меняет API без предупреждения, email отправляется второй раз. Backend становится медленным или нестабильным из-за внешних зависимостей. Что мы делаем: resilience-рефакторинг — timeout-ы, retry с экспоненциальной задержкой, идемпотентность по умолчанию, dead-letter queue, circuit breaker, понятная запасная стратегия для каждой интеграции.

Scenario · 05

“«Нужна событийная архитектура»”

Несколько сервисов или внутренних систем должны реагировать на одни и те же события (новый заказ → CRM + склад + email + аналитика + биллинг). Point-to-point интеграции не масштабируются, каждый новый получатель ломает что-то старое. Что мы строим: event bus (RabbitMQ, Kafka или Redis Streams в зависимости от масштаба), схему событий, publishers и subscribers с правильной обработкой ошибок, replay-ability для backfill, наблюдаемость по trace_id.

02 · Чего мы не делаем · Честное руководство по выбору

Четыре сценария, где лучше не идти к нам⁠.

Перед списком «что строим» — что не наша территория. Это сэкономит вам деньги и сроки. Мы не берём проект ради бюджета, если знаем подходящего исполнителя.

01

Кастомная 1С-разработка внутри конфигуратора

Мы не пишем код внутри конфигуратора 1С, не делаем кастомные печатные формы, не настраиваем типовую конфигурацию. Это специализация 1С-партнёров (Первый Бит, ITCraft, АКАМ). Мы интегрируемся С 1С через стандартные интерфейсы (REST, OData, XML-обмен), но кастомизацию самой 1С отдаём профильным студиям.

    02

    Шаблонные интеграции «от 8 тыс. ₽» из маркетплейса 1С-Битрикс

    Если задача — поставить готовый модуль из маркетплейса 1С-Битрикс и настроить три поля — это шаблонная работа, у неё свои исполнители. Готовая к проду интеграция со source of truth, идемпотентностью и журналом событий не бывает за 8 тыс. ₽. Если ожидание такое — мы не подходим, и это нормально.

      03

      Без кода как основная стратегия (Zapier, Albato, Make)

      Zapier, Albato и Make — отличные инструменты для прототипов, внутренних автоматизаций и quick wins. Для production-critical потоков (платежи, заказы, документооборот) они накапливают технический долг: нет контроля версий, нет тестов, нет нормальной обработки ошибок. Используем их сами для внутренних задач, но не строим на них продакшен-системы.

        04

        Регулируемые банковские интеграции уровня ЦБ-лицензии

        Прямая интеграция с банковским core, регулируемый платёжный шлюз с PCI DSS Level 1, банковская сертификация — нужны команды с профильными сертификациями и compliance-офицером. Не наш профиль. Платёжные интеграции через стандартных провайдеров (ЮKassa, Тинькофф, Stripe) — делаем.

          03 · Что мы делаем · Четыре архитектурных уровня

          От одной интеграции⁠ до event-driven архитектуры.

          Не «всё подряд по ТЗ». Четыре определённых архитектурных уровня, под которые у нас есть рабочие подходы и реальные кейсы. На спринте определяем, какой уровень нужен — это задаёт стек, формат работ и план реализации.

          01

          API design для своего продукта

          REST API с правильной моделью ресурсов или GraphQL, если правда нужен. OpenAPI 3.0 как источник истины для контрактов и документации. Стратегия версионирования (URL или header). Согласованная пагинация, фильтрация и сортировка. Единый формат ошибок с осмысленными кодами. Ограничения по скорости. Авторизация (OAuth, API-ключи, JWT). Postman-коллекции для developer experience. Подходит для нового продукта или major redesign существующего API.

          02

          Синхронные и асинхронные интеграции

          Синхронные — HTTP-клиент с timeout, retry с экспоненциальной задержкой, circuit breaker, кэширование, моки для тестов. Асинхронные — webhook receiver с HMAC-проверкой и IP-allowlist, идемпотентность по умолчанию, dead-letter queue, retry с jitter, журнал каждого входящего события. Webhook publisher для исходящих — повторные доставки, ротация секретов, журнал доставки. Закладывается с первого дня, не «потом доделаем».

          03

          Public API для партнёров и внешних разработчиков

          Промышленного уровня публичный API: developer portal, управление API-ключами, ограничения по скорости и квоты, sandbox-окружение, comprehensive-документация, SLA-фреймворк, понятная стратегия deprecation. Это отдельный класс задач, не «внутренний API, на который повесили читалку». Подходит для SaaS на стадии партнёрской программы.

          04

          Event-driven и ERP-class интеграции

          Event bus (RabbitMQ, Kafka, Redis Streams в зависимости от масштаба), схема событий, publishers и subscribers с retry, replay-ability для backfill, наблюдаемость по trace_id. Для крупных проектов — ERP-class интеграции с движками сверки, журнал событий для финансового аудита, обмен с mainframe и legacy-системами. Делаем когда продукт действительно вырос до распределённых событий.

          04 · Четыре ключевых решения до старта

          Архитектурные решения, которые дороже всего переделывать⁠.

          1. 01

            REST, GraphQL или gRPC

            REST — наш выбор по умолчанию для 90% проектов: понятная модель ресурсов, отличный tooling, зрелый OpenAPI-экосистема. Используем для стандартных SaaS, B2B, public API. GraphQL — когда правда нужен: сложный UI с разными запросами на одни данные, несколько клиентов с разными представлениями (web + mobile + admin), вложенные ресурсы с непредсказуемой глубиной. Дороже на старте ~30%, окупается на сложных UI. gRPC — для service-to-service внутри backend, высоконагруженного internal API, стриминга. Не подходит для публичных API и браузерных клиентов. Решаем по реальной задаче, не по «что модно».

          2. 02

            Синхронно или асинхронно

            Синхронно (HTTP request-response) — когда нужен ответ в real-time (поиск, валидация, логин), latency < 200 мс, простая модель, простой debug. Покрывает ~70% случаев в SaaS и B2B. Асинхронно (очередь, webhook, event bus) — когда операция занимает > 1 секунды (отправка email, генерация отчёта, синхронизация интеграции), нужна гарантия доставки с retry, нужна decoupling между producer и consumer. Гибрид (sync trigger → async processing) — часто правильный паттерн: endpoint валидирует вход и кладёт job в очередь, возвращает job_id, клиент опрашивает статус или получает webhook. Не делаем всё синхронно (медленный backend, timeouts), не делаем всё асинхронно (overengineering для простых запросов).

          3. 03

            Polling, webhooks или event streams

            Polling — для legacy-систем без поддержки webhooks (часто 1С), простая реализация, но latency и неэффективный трафик. Webhooks — для real-time обновлений и интеграций с современными SaaS (90% случаев). Плюсы — эффективно и быстро. Минусы — клиент должен иметь публичный endpoint, нужна обработка failures. Event streaming (Kafka, event bus) — для multiple consumers на одни события, replay-ability, высокая пропускная способность. Decoupling и масштабируемость в обмен на операционные overhead. Используем когда правда > 3 потребителей или нужна replay. Исходящие интеграции — webhooks по умолчанию, event streaming для сложного multi-consumer.

          4. 04

            Источник истины (source of truth)

            Каждая сущность должна иметь один источник истины. Без этого — данные расходятся, конфликты, ручная сверка, потерянные записи через 3–6 месяцев. Паттерн принятия решения для типичных сущностей: клиенты — если CRM активно используется командой, CRM является источником, sync в продукт; если продукт является primary touchpoint, продукт источник, sync в CRM. Заказы — если 1С первичная по бухгалтерии и складу, 1С источник; если первичная commerce-платформа, она источник, push в 1С. Каталог — если 1С товарная база, 1С источник, sync в сайт; если product management в продукте, продукт источник, push в маркетплейсы. На спринте фиксируем для каждой сущности: источник, направление синхронизации, правила разрешения конфликтов. «Двусторонняя синхронизация» без правил разрешения конфликтов = хаос через 3 месяца.

          05 · Технологический стек

          Подбираем инструменты под задачу и масштаб⁠, а не наоборот.

          Один из двух основных backend-стеков, PostgreSQL для журнала и аудита, проверенные библиотеки для очередей и retry — без зоопарка фреймворков. Выбор делается на спринте под конкретный масштаб и команду поддержки.

          API и контракты
          • REST · OpenAPI 3 · версии
          • GraphQL — когда правда нужен
          • tRPC — для tight TypeScript-связки
          • gRPC — service-to-service

          OpenAPI как источник истины, документация и клиенты генерируются из кода. GraphQL и gRPC — только под обоснованную задачу.

          Очереди и события
          • RabbitMQ — стандарт для очередей
          • BullMQ (Redis) — Node.js background-jobs
          • Kafka — high-throughput event streaming
          • Spring Async · Redis Streams

          RabbitMQ по умолчанию для message queuing. Kafka — только когда realistic scale (миллионы событий в день) и команда готова к операционному overhead.

          Интеграции
          • 1С · REST · OData · XML-обмен
          • AmoCRM · Битрикс24 · HubSpot · Salesforce
          • ЮKassa · Тинькофф · СБП · Stripe · Paddle
          • Ozon · Wildberries · Яндекс.Маркет

          CRM, 1С, платежи, маркетплейсы, склад, доставка, email/SMS, мессенджеры — через стандартные API. Кастомная 1С-разработка — у профильных партнёров.

          Наблюдаемость
          • Sentry · OpenTelemetry · trace_id
          • Grafana · Prometheus · логи
          • Идемпотентность · DLQ · повторы
          • Журнал событий в PostgreSQL

          Каждое изменяющее состояние событие в журнале с trace_id. Sentry для ошибок, Grafana для метрик, dead-letter queue для критичных сбоев с оповещениями.

          06 · Открытые цены · Семь форматов

          От integration-аудита до event-driven архитектуры⁠.

          Семь форматов с гибкой комбинацией. Можно начать с любого и остановиться после него — план работ остаётся у вас. Сроки до первой работающей интеграции — 2–3 недели независимо от тарифа, дальше итерации каждые 2 недели.

          Аудит

          Integration-аудит

          Разбор существующих интеграций: модель данных, контракты API, паттерны ошибок, производительность, безопасность. Список проблем по приоритету и понятный план. Часто результат — quick fixes (идемпотентность, retry, обработка ошибок), а не полное переписывание.

          от 100 000 ₽
          ├1–2 недели┤
          • Карта существующих интеграций
          • Аудит контрактов API
          • Проверка обработки ошибок и retry
          • Аудит безопасности webhooks
          • Список рисков с приоритетом
          • План работ на 3 месяца
          Заказать аудит
          Спринт

          Архитектурный спринт

          Integration architecture для нового проекта или крупного расширения: источник истины для каждой сущности, синхронные и асинхронные паттерны, карта интеграций, выбор очередей, точная смета на реализацию.

          от 150 000 ₽
          ├5 дней┤
          • Карта интеграций
          • Источник истины для каждой сущности
          • Решения sync vs async
          • Выбор очередей и event bus
          • Список рисков
          • Точная смета на сборку
          Запустить спринт
          Single integration

          Одна интеграция готовая к проду

          Одна интеграция доведённая до прода: синхронный или асинхронный паттерн, обработка ошибок, retry, идемпотентность, журнал событий, документация. Типичный сценарий — сайт ↔ CRM, сайт ↔ 1С, платёжная интеграция, маркетплейс ↔ склад.

          от 200 000 ₽
          ├2–4 недели┤
          • API-контракт или паттерн обмена
          • Sync или async с обоснованием
          • Обработка ошибок и retry
          • Идемпотентность по умолчанию
          • Журнал событий в PostgreSQL
          • Runbook и документация
          Обсудить интеграцию
          Чаще выбирают
          Integration layer

          Интеграционный слой (3–5 систем)

          Полноценный интеграционный слой для существующего сайта или продукта: CRM + 1С + платежи + email + склад. Архитектурно правильно, с идемпотентностью, журналом и обработкой ошибок. Без хаоса из самописных скриптов.

          от 500 000 ₽
          ├6–10 недель┤
          • Источник истины для каждой сущности
          • 3–5 интеграций готовая к проду
          • Единый журнал событий
          • Dead-letter queue и оповещения
          • Документация обмена
          • Передача и обучение команды
          Обсудить слой
          API design

          Дизайн и реализация API

          Дизайн и реализация API для нового продукта или major redesign существующего: REST или GraphQL контракты, стратегия версионирования, авторизация, ограничения по скорости, документация, onboarding для разработчиков.

          от 400 000 ₽
          ├4–8 недель┤
          • REST или GraphQL контракты
          • OpenAPI как источник истины
          • Стратегия версионирования
          • Авторизация и ограничения
          • Postman-коллекции
          • Документация и примеры
          Обсудить API design
          Public API

          Публичный API для партнёров

          Промышленного уровня публичный API: developer portal, управление API-ключами, ограничения по скорости, sandbox-окружение, comprehensive-документация, SLA-фреймворк, стратегия deprecation. Отдельный класс задач, не «открыли внутренний API наружу».

          от 800 000 ₽
          ├6–12 недель┤
          • API design под публичный доступ
          • Developer portal
          • Управление ключами и квотами
          • Sandbox-окружение
          • SLA-фреймворк и deprecation
          • Onboarding-флоу разработчиков
          Обсудить публичный API
          Event-driven · ERP

          Event-driven и ERP-class

          Шина событий (RabbitMQ, Kafka), схема событий, publishers и subscribers, возможность replay для backfill, наблюдаемость. Для задач корпоративного уровня — движки сверки с провайдером, журнал событий для финансового аудита, обмен с mainframe и сложными legacy-системами. От 2 млн ₽ для сценариев корпоративного уровня.

          от 1 200 000 ₽
          ├8–20 недель┤
          • Event bus под масштаб
          • Схема событий и контракты
          • Publishers и subscribers с retry
          • Replay-ability для backfill
          • Reconciliation (для ERP)
          • Audit-trail для compliance
          Обсудить архитектуру
          07 · Почему H-Studio для API и интеграций

          Интеграция — инженерная дисциплина⁠, а не «настроить модуль».

          1. 01

            Интеграция как инженерия, не шаблонная работа

            Большинство студий на российском рынке подают интеграцию как «подключим модуль из маркетплейса 1С-Битрикс» или «настроим webhook между AmoCRM и сайтом». Это шаблонная работа — копирование конфигурации. У нас другой уровень: модель данных, источник истины, обработка ошибок, retry с экспоненциальной задержкой, идемпотентность, журнал событий, наблюдаемость. Это другой уровень reliability и поддерживаемости.

          2. 02

            Source-of-truth-мышление с первого дня

            Каждая интеграция начинается с вопроса «где живут данные правды?». Без чёткого ответа — гарантированные конфликты через 3–6 месяцев. Мы фиксируем для каждой сущности (клиент, заказ, товар, документ) источник истины + направление синхронизации + правила разрешения конфликтов. Это решается до того, как будет написана первая строка кода интеграции.

          3. 03

            Async-by-default для интеграций

            Внешние сервисы зависают, дублируют события, меняют ответы, падают. Если ваша система блокируется на них (sync-вызовы без timeout, retry и circuit breaker) — это нестабильная архитектура. Наш паттерн по умолчанию: sync trigger → async processing с правильной обработкой ошибок. Endpoint быстро отвечает клиенту, heavy lifting в background-job, retry с экспоненциальной задержкой при сбоях, dead-letter queue для критичных, журнал событий в БД.

          4. 04

            Идемпотентность как дефолт, а не «потом»

            Внешние сервисы дублируют события. ЮKassa может отправить payment.succeeded дважды из-за сетевых проблем, AmoCRM иногда повторяет webhooks при таймауте, наш собственный retry может вызывать дубли. Без идемпотентности — двойные списания, дубли заказов, порча данных. По умолчанию: каждая операция, изменяющая состояние, имеет idempotency key. Повтор не повторяет операцию, а возвращает кэшированный результат.

          5. 05

            Честно о 1С — честное руководство к 1С-партнёрам

            Мы не 1С-специалисты. Не делаем кастомную разработку внутри конфигуратора 1С. Делаем backend для продукта, который интегрируется с 1С через стандартные интерфейсы (REST, OData, XML-обмен, файлы). Для кастомной 1С-разработки рекомендуем профильных партнёров (Первый Бит, ITCraft, АКАМ). Это сэкономит вам время и деньги, если задача внутри 1С.

          6. 06

            Senior-команда без джунов

            Integration architecture inherently senior-работа: решения по источнику истины, async-паттернам, resilience-дизайну. Джун может закодить API-вызов. Решить «что делать, когда webhook от AmoCRM приходит дважды, а сумма не совпадает с CRM-данными» — не может. Та же senior-команда от спринта до запуска: основатель и стратегия, проектный лид, инженерный лид, дизайн-лид.

          08 · Чего у нас не бывает · Анти-паттерны

          Четырнадцать решений, после которых интеграции ломаются через 3 месяца⁠.

          Это то, что мы видим у конкурентов, в чужих кодовых базах и на собеседованиях. У нас — нет. Часть из этого — про моду, часть — про экономию на senior-инженерах, часть — про подмену архитектурных решений «у нас же все так делают».

          • Шаблонные интеграции «за 8 тыс. ₽» — копирование модулей из маркетплейса 1С-Битрикс, без журнала, идемпотентности и обработки ошибок
          • Zapier и Albato как primary integration strategy для production-critical потоков — нет тестов, нет контроля версий, нет нормальной обработки ошибок
          • Интеграции в коде фронтенда — вызовы к внешним API из браузера = security-дыра + неконтролируемые ошибки + риск утечки ключей
          • Polling там, где есть webhooks — overhead и latency без причины, кроме «у нас всегда так делали»
          • Кастомная retry-логика, когда есть проверенные библиотеки (BullMQ, Spring Retry) — переоткрытие колеса с собственными багами
          • Webhooks без HMAC-подписи и IP-allowlist — открытая security-дыра, кто угодно может отправить вам платёж.succeeded
          • Без идемпотентности — гарантированный double-charge или дубли заказов через 3 месяца продакшена
          • «Двусторонняя синхронизация» без правил разрешения конфликтов — хаос через 3–6 месяцев, ручная сверка раз в неделю
          • Без журнал событий — для compliance, debugging и поддержки клиентов всегда нужен журнал каждого изменяющее состояние события
          • Kafka для проекта с 5 пользователями в день — операционный overkill, RabbitMQ или Redis достаточно
          • «Шина данных» как overengineering для маленьких проектов — паттерн Service Bus уместен только когда realistic scale его требует
          • Workflow-логика разбросана по API-endpoints вместо конечного автомата в БД — хаос для debugging и поддержки
          • Кастомная авторизация для каждой интеграции — используем стандарты (OAuth 2.0, API-ключи, JWT)
          • Передача джунам после первого месяца и чёрный ящик в репозитории подрядчика — у нас integration map, API-документация и runbook в вашем GitHub с первого дня
          09 · Где мы на спектре · Самоопределение

          Между без кода и корпорат-сегментом⁠.

          Без кода (Zapier, Albato, Make) — для прототипов и внутренних автоматизаций. 1С-Битрикс-специалисты — для интеграций внутри 1С-экосистемы и кастомной 1С-разработки. H-Studio — оптимум для основателей и компаний со сложными интеграционными задачами (несколько систем, async, журнал событий) и бюджетом 200 тыс. – 3 млн ₽. Корпорат (Рексофт, СимбирСофт, Андагар) — для регулируемых ERP-class интеграций и проектов с большими командами.

           
           
          Без кода
          Zapier · Albato · Make
          1С-Битрикс специалисты
          Первый Бит · ITCraft · АКАМ
          H-Studio
          Integration engineering
          Корпорат-интеграции
          Рексофт · СимбирСофт · Андагар
          Цена
          $20–200/мес + setup
          50–300 тыс. ₽
          200 тыс. – 3 млн ₽
          3–15 млн ₽+
          Срок
          Часы–дни
          1–4 недели
          2–20 недель
          3–12 месяцев
          Что покрывают
          Простые CRUD-связки
          1С + AmoCRM + Битрикс24
          Полная integration architecture
          ERP-class и регулируемое
          Кастомная логика
          Очень ограничена
          Только в 1С-экосистеме
          Полная
          Полная
          Кастомная 1С-разработка
          Нет
          Их specialty
          Не делаем
          Иногда
          Обработка ошибок и retry
          Базовая
          Базовая
          Промышленного уровня
          Enterprise-grade
          Идемпотентность
          Ограниченно
          Часто нет
          По умолчанию
          По умолчанию
          Public API для партнёров
          Нет
          Нет
          Да
          Да
          Event-driven
          Нет
          Нет
          Да
          Да

          Самоопределение · выберите свой формат

          10 · Интеграционные кейсы в портфолиоОткрыть полный архив→

          Четыре кейса с разными интеграционными паттернами⁠.

          Каждый — реальная интеграционная задача в продакшене. В тегах — архитектурный тип и стек, чтобы было видно, где event-driven, где multi-source, где биллинг повторяющихся подписок, где offline-sync.

          Тип · Event-driven · RabbitMQ · идемпотентные платежи

          Creator Marketing Platform

          Мульти-арендный SaaS-маркетплейс. Асинхронная синхронизация поставщиков для 1 200+ услуг через RabbitMQ с retry и идемпотентностью. Движок цен с переопределениями на нескольких уровнях. Идемпотентные платежи и возвраты. Operator-grade админ-инструменты с audit-middleware на каждый изменяющее состояние вызов. Стек: Java/Spring Boot, RabbitMQ, PostgreSQL, Redis, очереди.

          Открыть кейс→
          Тип · Multi-source · Anthropic API · маркетплейс

          My Office Asia

          PropTech-маркетплейс гибких офисов в Гонконге. Несколько источников каталога зданий (building catalogues, operator APIs, внешние data-источники). Anthropic Claude API для AI-функций с правильным rate-limiting, retry и журналом расходов. Архитектура заложена на несколько рынков. Стек: Next.js, Supabase, Anthropic API, NestJS, pgvector.

          Открыть кейс→
          Тип · Mobile API + offline sync · WhatsApp Business

          Vulken FM

          Платформа facility management. Mobile API для инспекций на объектах без интернета: загрузка файлов с metadata, JWT-авторизация, разрешение конфликтов при concurrent edit-ах, очереди для синхронизации с мобильным offline-режимом. WhatsApp Business для уведомлений инженеров. Стек: NestJS, TypeScript, PostgreSQL, S3, WhatsApp API.

          Открыть кейс→
          Тип · ЮKassa с повторными списаниями · подписочный биллинг

          Web Page Generator

          SaaS с биллинг повторяющихся подписоком. ЮKassa-повторных списаний для подписок, ограничение функций по тарифу на сервере (не в UI), quote-signing для целостности checkout, идемпотентная обработка платежей, журнал событий изменений подписок. Стек: Next.js, TypeScript, Supabase, ЮKassa, webhooks.

          Открыть кейс→
          FAQ · Четырнадцать вопросов про API и интеграции

          1. CRM — AmoCRM, Битрикс24, HubSpot, Pipedrive, Salesforce, любые с REST API. 1С — REST API из 1С, OData, XML-обмен, прямая интеграция с БД 1С если доступна. Платежи — ЮKassa, Тинькофф Касса, СБП, Сбер Эквайринг, Stripe, Paddle. Маркетплейсы — Ozon Seller, Wildberries, Яндекс.Маркет, Мегамаркет. Склад — Мой Склад, 1С:УНФ, кастомные WMS. Доставка — СДЭК, Boxberry, DPD, Почта России. Email/SMS — SendGrid, Brevo, Mailgun, SMS.RU, SMSC. Мессенджеры — Telegram Bot API, WhatsApp Business через провайдеров. Аналитика — Яндекс.Метрика, GA4, Mixpanel, Amplitude. В целом — любая система с публичным API.

          Дальше · Поехали

          Соберём интеграции, которые не сломаются через 3 месяца⁠.

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

          30-минутный архитектурный созвонОценить проект
          Студия
          H-Studio
          Senior-поставка · Москва · Россия
          Контакт
          +7 (982) 666-66-80
          Офис
          ул. Октябрьская д. 80 стр. 6
          117593 Москва