Как связать 1С с европейскими сервисами через API

У части русскоязычного бизнеса в ЕС операционная картина выглядит так: бухгалтерия и учёт годами велись в 1С или похожей системе, а продажи, оплаты и клиентский сервис постепенно переехали на европейские инструменты — Stripe для платежей, Shopify или WooCommerce для магазина, отдельная CRM для клиентов. По отдельности каждый инструмент работает нормально. Проблема начинается там, где между ними нужно передавать данные — и этот перенос до сих пор делает человек, вручную, каждый день или каждую неделю.

Почему это не решается «просто выгрузкой»

Первая идея обычно — настроить регулярную выгрузку в CSV и загрузку с другой стороны. Это работает ровно до первого расхождения: оплата прошла в Stripe, но заказ не появился в 1С, потому что файл выгрузился на пять минут раньше, чем платёж подтвердился. Или наоборот — выгрузка успешно легла, но с ошибкой в одном поле, и это выясняется только когда бухгалтер сводит месяц и не может понять, откуда взялась разница в отчёте. Ручной перенос данных не масштабируется и не самовосстанавливается: если он сломался в четверг, никто не узнает об этом до конца месяца.

Настоящая интеграция — это не файл, который кто-то раз в день открывает и импортирует, а связь между системами, которая работает сама и говорит, когда что-то пошло не так.

Из чего состоит нормальная интеграция

Очереди и повторные попытки. Если система на другом конце недоступна в момент запроса — упала, обновляется, отвечает медленно — событие не должно потеряться. Оно встаёт в очередь и повторяется автоматически, пока не пройдёт, вместо того чтобы просто исчезнуть.

Идемпотентность. Один и тот же платёж не должен создать два заказа, даже если система по какой-то причине получила уведомление о нём дважды — такое случается чаще, чем кажется, из-за особенностей вебхуков на стороне платёжных провайдеров.

Мониторинг и алерты. Если интеграция перестала работать, об этом должен узнать человек в течение минут, а не в конце месяца при сверке отчётов. Настроенный алерт стоит на порядок дешевле, чем найденное постфактум расхождение в бухгалтерии.

Runbook. Письменная инструкция на случай сбоя — что проверить первым, куда посмотреть, как перезапустить конкретный участок цепочки, — вместо того чтобы каждый инцидент разбирать заново с нуля, полагаясь на память одного человека, который когда-то это настраивал.

Когда у системы нет API

Не у каждой системы, с которой нужно связаться, есть удобный API — особенно если это внутренняя или отраслевая система, которую никто не обновлял годами. В таком случае у нас есть рабочий порядок предпочтений: сначала — обмен файлами по расписанию через защищённый канал, если формат стабилен и предсказуем. Если и этого нет — плановые экспорты по расписанию с валидацией на входе, чтобы битый файл не испортил данные на другой стороне. И только как самый последний вариант, когда ничего из перечисленного недоступно, — документированная автоматизация через браузерный интерфейс системы, оформленная так, чтобы её можно было объяснить и передать другой команде, а не «скрипт, который работает, пока никто не трогает верстку сайта».

Почему это частая ситуация именно здесь

У русскоязычного бизнеса в Эстонии и шире по Балтии и ЕС эта ситуация возникает чаще, чем у соседних компаний с другой историей, по понятной причине: учётные привычки и системы складывались годами в одной среде, а рынок и клиенты — уже в другой. Это не повод что-то менять ради самого факта смены системы. Старая система, в которой бухгалтер уверенно работает десять лет, часто эффективнее новой, которую придётся заново осваивать — вопрос не в том, чтобы её заменить, а в том, чтобы она перестала требовать ручного ввода данных, которые уже существуют в другой системе в цифровом виде.

Где в этом GDPR

Как только данные начинают перетекать между системами, встаёт вопрос — где именно они физически хранятся и обрабатываются на каждом шаге. Для бизнеса, работающего с клиентами в ЕС, это не формальность: если платёжные данные идут через Stripe, попадают в очередь на промежуточном сервере, а затем в отчётную систему, каждая точка в этой цепочке должна быть понятной с точки зрения того, где живут данные и кто имеет к ним доступ. Мы закладываем это в архитектуру интеграции с самого начала, а не добавляем задним числом после вопроса от клиента или аудита: минимальный сбор данных, понятные потоки, и там, где это уместно, размещение инфраструктуры внутри ЕС. Если для вашей интеграции важна локализация данных или вы уже думаете о переносе части инфраструктуры в облако с учётом требований ЕС, это соседняя тема — она подробнее раскрыта на странице про облако и DevOps.

Что мы уже подключали

За годы работы мы связывали между собой Shopify, WooCommerce, Stripe, различные отраслевые ERP и CRM, API телематики и операторов eSIM, сети IoT-датчиков по протоколу MQTT. Логика в каждом случае разная, но подход один и тот же: middleware-слой, который знает про очереди, идемпотентность и мониторинг, а не прямая связь «от системы А напрямую к системе Б», которая красиво работает на демо и разваливается на реальном объёме данных через месяц.

Компонент интеграции	Зачем он нужен
Очередь с повторными попытками	Событие не теряется, если система на другом конце временно недоступна
Идемпотентность	Один платёж не создаёт две записи при повторном вебхуке
Мониторинг и алерты	О сбое узнают в течение минут, а не при сверке в конце месяца
Runbook	Инцидент решается по инструкции, а не по памяти одного человека

Правило, которым мы пользуемся

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

Если у вас похожая ситуация — данные, застрявшие между системами, которые должны говорить друг с другом, но не говорят — опишите нам обе системы, и мы скажем, что из перечисленного выше подойдёт в вашем случае. Подробнее о том, как мы это делаем, — на странице интеграций, а обзор остальных услуг — на странице услуг.