Когда у вас один‑два сервиса и несколько интеграций, внешний API легко держать под контролем. Но если их десятки и каждый хочет выставиться наружу, приходится придумывать свой велосипед.
Меня зовут Юрий Коберман, я технический продакт в Точка Банк. Мы в команде несколько раз меняли систему работы с API. Начинали с одной команды, которая писала всё вручную, и постепенно пришли к универсальному инструменту, с помощью которого сервисы могут выходить наружу самостоятельно без очереди и потери качества. Подробности — в этой статье.
Зачем нужно внешнее API
Мы в Точка Банк используем внешнее API, чтобы клиенты могли интегрировать банк и дочерние сервисы в свои системы. Проще говоря, даём возможность получать банковские данные не через интерфейс банка, а напрямую — с помощью кода.
Например, у клиента есть собственная CRM, в которой работают менеджеры и бухгалтерия. Без интеграции им нужно зайти в банк, чтобы посмотреть баланс и сделать выписку — это неудобно и долго. С API система сама отправляет запрос в банк, получает данные и автоматически отображает их в сервисе.
Чаще всего внешнее API используют:
Клиенты банка: обычные пользователи, которые создают интеграции для личного пользования. Например, владельцы интернет‑магазинов, которые внедряют платёжный модуль на свой сайт.
Партнеры: крупные сервисы, которые монетизируют интеграцию с банком — бухгалтерские системы, сервисы учёта и отчётности для предпринимателей.
Таким образом, API помогает выставить банковский функционал наружу и сделать так, чтобы любой наш продукт можно было использовать вне банковского контура.
Как устроена работа с API в Точка банк
За несколько лет мы сменили три разных подхода к работе с API. Расскажу подробно про плюсы и минусы каждого.
Централизованная модель
Внешние API в Точка Банк существуют с 2018 года. До середины 2024 года за них отвечала только наша команда. Если какой‑то сервис банка хотел «выйти наружу», к нам приходил заказчик, описывал продукт, задачу и мы начинали работу. А после — отвечали за поддержку.
Для этого нам приходилось тесно общаться с заказчиками и глубоко погружаться в бизнес‑логику: разбираться в типах документов, форматах счетов и других вещах, которые напрямую не относятся к API, но нужны, чтобы решать вопросы клиентов.
У такой модели были свои плюсы:
Контроль качества: мы писали весь код сами, знали, как работает интеграция, как быстро её починить или изменить.
Единообразие: использовали одинаковый подход к работе, стилю и структуре API.
Прозрачность: было понятно, кто отвечает за внешний API и к кому идти с вопросами или проблемами.
Исторически это решение казалось единственно верным. Сервисов, которые хотели выставиться наружу, было немного, поэтому команда успевала держать всё под контролем. Но со временем количество желающих стало расти. Из‑за этого:
сроки стали регулярно сдвигаться;
мы теряли фокус из‑за постоянных переключений между задачами;
нагрузка на команду сильно выросла.
В какой‑то момент стало очевидно, что централизованная модель нам больше не подходит.
Аутсорс разработчиков от сервисов
В середине 2024 года мы полностью поменяли формат работы и начали привлекать на аутсорс разработчиков от сервисов.
Идея была простой: сервис выделяет своего программиста, который временно приходит в команду API и реализует нужный функционал. При этом мы не напрягаем его нашими обязательными встречами, типа дейликов, но добавляем во все общие чаты, чтобы можно было оперативно получить помощь и поддержку. Фактически на время разработки сервис «терял» одного разработчика (иногда больше), а команда API получала дополнительные руки.
С помощью этой модели мы смогли ускорить свой time‑to‑market и избавиться от очереди. Но возникли другие проблемы, которые со временем стали перевешивать плюсы:
Разный стек технологий: команда API писала на Python, а сервисы внутри банка часто использовали php, Java и другие языки программирования. Если у сервиса не было питониста или свободного сотрудника, они не могли никого отправить к нам в команду.
Качество и единообразие: у приходящих разработчиков было своё видение и подходы к работе. Иногда это было полезно, иногда вело к конфликтам. Появлялся код, который выбивался из общего стиля.
Трудности с тестированием: было не понятно, кто им занимается. У команды API всё ещё были ограничены ресурсы, а если тестировала команда сервиса, то проверялся только реализованный функционал без полного прохождения бизнес‑логики, из‑за чего периодически появлялись критичные баги.
При этом поддержка клиентов оставалась за командой API. Это накладывало дополнительную нагрузку на наших саппортов — им по прежнему приходилось изучать бизнес‑логику большого количества сервисов. Спустя полтора года мы поняли, что выросли из этой модели и снова нужно что‑то менять.
Универсальный инструмент
В начале 2025 года мы запустили универсальный инструмент, которым пользуемся до сих пор.
Теперь команды, которые стремятся наружу, могут:
Взять свой код и описать API в привычном стеке и формате.
Передать это описание на платформу API.
Пройти автоматическую проверку и валидацию.
Получить метод, опубликованный во внешнем API и документации.
Так как внутри банка используют разные языки программирования, мы заложили механизм конвертации. Благодаря этому сервисы могут писать как им удобно, а мы — поддерживать единообразие кода.
Помимо этого, у подхода есть другие преимущества:
Скорость: сервисы могут выходить наружу самостоятельно и не ждать очередь.
Удобство: ручной труд команды API сведён к минимуму, поэтому процесс легко масштабируется.
Централизованная работа с аутентификацией: за все токены и ключи запросов отвечает команда API, продуктовым командам больше не нужно реализовывать собственную логику аутентификации.
Поддержка: за внешний API отвечает продуктовая команда, которая его публикует. Наша команда перестала забирать бизнес‑логику к себе, а саппорты с облегчением выдохнули.
На создание MVP у нас ушло около двух месяцев. Сегодня через универсальный инструмент уже выставлены несколько продуктовых сервисов: для работы с безопасными сделками, банковскими гарантиями и приёма интернет‑платежей для крупных клиентов с сертификатом PCI DSS. Думаю, скоро их станет больше — инструмент изначально проектировался с учётом будущего роста.
Чем теперь занимается команда API?
Если раньше наша команда писала внешние API и брала на себя бизнес‑логику, поддержку и общение с клиентами, то теперь мы стали своеобразной мастер‑системой.
Наша задача — не писать API за другие команды, а предоставлять им инструмент, правила и инфраструктуру, с помощью которых они будут делать это самостоятельно.
Теперь наш фокус работы сместился на:
построение платформы;
формирование гайдлайнов и чейнджлогов с изменениями;
автоматизацию проверок;
контроль качества и единообразия.
Каждый месяц мы проводим общую встречу, где решаем текущие вопросы, обсуждаем приоритеты, делимся новостями, смотрим метрики, статистику и роадмап. Если у двух команд одновременно горят сроки и нужна наша помощь, то сводим их между собой, чтобы они самостоятельно договорились об очерёдности.
Также инструмент приходится периодически дорабатывать, так как по мере подключения новых сервисов всплывают неочевидные и уникальные кейсы.
Наши ошибки
Оглядываясь назад, могу выделить три главных ошибки, которые мы допустили:
Хватались за всё сразу: после появления MVP сразу несколько сервисов захотели подключиться к новому инструменту. Он был ещё «сырой» и это привело к тому, что мы запутались сами и запутали другие команды.
Недооценили важность документации: на старте делали её «на коленке» и дорабатывали на ходу. Но когда появился чёткий и понятный гайдлайн, вопросов и ошибок стало меньше.
Мало общались со стейкхолдерами: фактически у нас поменялось само понятие «клиента». Если раньше это были внешние клиенты Точка Банк, то теперь — наши внутренние сервисы. Важно поддерживать постоянный диалог, чтобы инструмент отвечал реальным потребностям пользователей.
Можно сказать, что почти все наши ошибки были не техническими, а организационными. Сам инструмент можно допиливать на ходу, но отсутствие фокуса и документации превращает даже хорошую идею в источник хаоса.
Кому нужен универсальный инструмент?
Если вы используете внешние API для единичных интеграций, универсальный инструмент будет избыточным. Но он точно подойдет компаниям, где:
Есть много внутренних сервисов, к которым подключаются внешние партнёры и клиенты.
Каждая команда выставляет API по‑своему, из‑за чего не соблюдается единообразие сервисов.
Нет единого контроля качества и валидации внешних API.
Возможно, через год‑два мы решим снова поменять подход к работе, но сейчас он полностью удовлетворяет потребностям бизнеса — помогает разгрузить команду, масштабировать внешний API и сохранить качество кода.
