Примеры работ и кейсы по направлению «Интеграция по API»

Проект для Würth Russia по подготовке перехода исторической базы торговых операций с Informix 1997 на SAP. Проведён анализ структуры и связей торговых данных, подготовлена схема миграции и соответствия данных для переноса в новую корпоративную систему. Проект выполнялся давно, поэтому архивные интерфейсы и документы не сохранились. На иллюстрациях показан текущий публичный сайт компании; предмет кейса – архитектура миграции данных, а не разработка этого сайта.

Проект по автоматизации торговли автозапчастями AVD Motors. Выполнены бизнес-анализ процессов, проектирование решения и API-интеграции для объединения веб-интерфейса с рабочими системами компании. Проект охватывал каталог и поиск автозапчастей, обработку заказов и поддержку электронной торговли. Кейс сочетает аналитику, автоматизацию бизнеса, веб-разработку и интеграционную работу.

Мой сайт - https://makhnev.site/ Телеграм для связи - @notequal21

Мой сайт - https://makhnev.site/ Телеграм для связи - @notequal21

Мой сайт - https://makhnev.site/ Телеграм для связи - @notequal21

Отказоустойчивый слой между приложением и LLM-провайдерами: при сбое или лимите сам переключается на следующий ключ/модель/провайдера. Своя Python-библиотека (MIT), собрана по TDD. Задача: AI-фича падает, когда провайдер отвечает 429/5xx; на free-тирах это постоянно; легко жечь бюджет на flagship-моделях; вендор-лок на одном API. Нужен переиспользуемый инфраслой. Решение — llm-rotator (asyncio + httpx, Pydantic v2): — Model-First routing: провайдер (priority) → группа моделей (tier) → все ключи до даунгрейда. — Circuit Breaker: 429 → блок ключ+модель по TTL; 401/402 → ключ мёртв глобально; 5xx → 1 retry → дальше. Заблокированная комбинация пропускается без HTTP. — Квоты (токены/запросы) с гранулярностью модель/группа/ключ и сбросом daily/rolling; исчерпанный кандидат — без запроса к API. — Tier ceiling через RoutingContext: простые задачи не жгут flagship-квоту. — Хуки (before_request/after_response/on_fallback) для бюджета на стороне клиента (low coupling). — Единый tool calling/structured output, LangChain drop-in, streaming, embeddings, Redis + InMemory бэкенды. Результат: 2578 строк кода / 6459 тестов (≈2.5:1), 24 тест-файла, 3 семейства провайдеров, CI, semver, MIT. Работает в проде: матчинг резюме, контент-система, Дзен-бот. Стек: Python 3.11+ · asyncio · httpx · Pydantic v2 · Redis · LangChain · pytest

Для кого: Для компании, у которой данные между 1С:Бухгалтерия 8.0 и Битрикс24 не синхронизировались автоматически, что приводило к ручному переносу информации, риску ошибок и дополнительным затратам времени сотрудников. Решение Команда Codex IT разработала отдельный интеграционный веб-сервис на Node.js, выступающий единым шлюзом обмена данными между 1С и Битрикс24. В рамках проекта были реализованы: – разработка API для приема данных из 1С – разработка API для передачи данных в Битрикс24 – разработка механизмов приема данных из Битрикс24 – разработка механизмов передачи данных в 1С – построение двустороннего обмена между системами – реализация очередей синхронизации – система логирования операций – обработка ошибок и контроль корректности передачи данных – мониторинг статусов обмена – защита от потери данных при сбоях Результаты: – автоматизирован обмен данными между 1С и Битрикс24 – исключен ручной перенос информации между системами – снижено количество ошибок при работе с данными – реализована централизованная система контроля обмена – обеспечена прозрачность всех операций благодаря логированию – повышена скорость обработки информации внутри компании – создана масштабируемая интеграционная платформа для дальнейшего развития

Анонимизированный пример интеграционной работы: нужно было связать заявки с сайта, CRM и внутренние уведомления в один проверяемый процесс. Что было сделано: - разобрал входные формы, статусы и обязательные поля; - спроектировал обработку заявки через API: валидация, отправка, повторы при временных ошибках; - добавил журнал событий и понятные статусы обработки; - предусмотрел уведомления ответственным, чтобы ошибки не терялись; - описал, какие данные нужны для приемки и как проверять сценарий после запуска. Стек и подход: REST API, webhooks, Java/Spring Boot, React/TypeScript, Python/FastAPI или Django, PostgreSQL, Docker, логирование и обработка ошибок. Результат: вместо ручной передачи заявок появился устойчивый процесс с прозрачной историей обработки. Такой сценарий можно масштабировать на новые формы, каналы и CRM-интеграции.

Контакты: Телеграм: @itskleverbaby Телефон: +79255926213 Email: slava.klevleev@gmail.com Серверная часть для сервиса, где данные должны обновляться у всех пользователей сразу, без перезагрузки страницы. Laravel 12: события летят через WebSockets на Laravel Reverb, тяжёлые операции уходят в очередь через Kafka и не тормозят интерфейс, доступ закрыт JWT. API описано в Swagger — фронтенд или мобильные разработчики подключаются без лишних созвонов. Связка real-time с очередями — типовая история для чатов, дашбордов, торгов, любых сервисов с живыми данными. Здесь она собрана аккуратно и задокументирована.

Контакты: Телеграм: @itskleverbaby Телефон: +79255926213 Email: slava.klevleev@gmail.com Крупный вуз переводил приёмную кампанию в онлайн. Через ЛК ежегодно проходит больше 30 тысяч абитуриентов: подача документов, отслеживание статуса заявлений, справки — без очередей и звонков. Кабинет существовал до меня — я подхватил разработку, когда ушёл прежний начальник отдела автоматизации, и сам возглавил отдел. Несколько лет вёл и развивал проект в продакшене, в пике в команде было до трёх человек. Предметная область тяжёлая: 117 сущностей, около 490 миграций, конкурсы, квоты, документы, запись на мероприятия. Кабинет собирает статусы заявлений из внешних систем, синхронизируется с учётной системой вуза в обе стороны, сам генерирует PDF-справки с QR-кодом и выгрузки в Excel. Для сотрудников — админка с ролями, правами и двухфакторной авторизацией, каждое действие пишется в журнал. После перехода вуза на подачу через ЕПГУ я доработал отслеживание статусов и синхронизацию данных через АИС. Отдельно сделал запись на дни открытых дверей: раньше люди толпились у стоек регистрации, а сотрудники вручную искали ФИО в таблице — теперь регистрация идёт по сканированию QR-кода, очередей нет. Таких точечных фич под задачи управления по работе с абитуриентами было много. Система отработала несколько кампаний подряд и работает дальше.