Портфолио и кейсы фрилансеров по интеграции по API

AdPayer — платформа пополнения рекламных кабинетов (fintech/ad-tech). Я единственный разработчик проекта: fullstack на Python/FastAPI, идемпотентные платежи, автоматическая сверка транзакций, приём и обработка вебхуков от платёжных провайдеров, хранение состояния в PostgreSQL. Репозиторий приватный (коммерческий проект), поэтому публичной ссылки нет.

Push-инфраструктура для SimpleX Chat от Google Задача: Добавить push-уведомления в мессенджер SimpleX Chat, чтобы сообщения приходили независимо от статуса приложения. Реализовано: Синхронизация подписок Android-клиента с сервером через собственный push-gateway. Регистрация, обновление и отзыв push-токенов. Связывание очередей сообщений с push-токенами. Wake-up Android-клиента для доставки уведомлений. Защита API push-gateway. Интеграция с Firebase Cloud Messaging. Дополнительно: Доработка серверной инфраструктуры SimpleX: взаимодействие SMP-сервера с push-gateway и сборка Android-клиента. Стек: Kotlin, Android, Firebase Cloud Messaging, Node.js / NestJS, PostgreSQL, Docker, Nginx, Linux. Работа: Android-интеграция, backend, API, Docker-инфраструктура, серверная интеграция.

Я делал партнёрский бот для клиники: один бэкенд, два мессенджера и учёт оплат в Bitrix24. Партнёр регистрируется, получает ссылку и QR, смотрит штуки и сумму. Менеджер модерирует заявки в Telegram. Я собрал регистрацию: анкета, оферта с фиксацией версии и времени, статус самозанятый / ИП, очередь «на модерации». Менеджер подтверждает или отклоняет с причиной. В Max — кабинет партнёра (ссылка, QR, статистика); модерация заявок в Max не ведётся. Я выдал партнёру UTM-ссылку с его ID. В Bitrix24 считаю сделки воронки с этим UTM: за месяц и всего, выплата = число оплативших × ставка. Ежемесячный отчёт партнёру по расписанию. Я написал общий слой данных: одна база на Telegram и Max, аудит действий, заглушка статистики, пока webhook CRM не подключён, и живой запрос к Bitrix, когда webhook есть. Стек: Python, aiogram, Max Bot API, Bitrix24 webhook, SQLite/PostgreSQL, QR. NDA: клиника не публикуется.

Я делал связку Tenderplan и ChatGPT для поставщика оборудования: из мониторинга закупок собирается таблица, по каждой строке модель готовит черновик. На ЭТП ничего не уходит — человек правит и подаёт сам. Я написал выгрузку по API Tenderplan: сохранённые ключи поиска, доп. отбор по рынку, фильтры (поставка, не ЗИП и не услуги, окно дедлайна 5–14 дней). Результат — Excel с ссылками на извещения, сортировка по сроку. Я подключил ChatGPT: нет НМЦ — черновик коммерческого предложения (запрос цены); есть НМЦ — черновик заявки. Промпт запрещает выдумывать цены и реквизиты; если данных мало — пометка, что добрать. Я собрал пакет под Windows: встроенный Python, запуск одним bat, лог, инструкция. Всё остаётся на диске заказчика, в облако само не уходит. Стек: Python, Tenderplan API, OpenAI API, Excel (openpyxl). NDA: заказчик не публикуется.

NoFilter — self-hosted AI-платформа на базе open-source LLM Разработал собственный conversational AI-сервис с развертыванием языковой модели на собственной инфраструктуре. В проекте реализовал: — интеграцию и запуск open-source LLM; — собственную инфраструктуру для inference; — диалоговый интерфейс; — поддержку контекста и продолжительных диалогов; — голосовое взаимодействие; — различные режимы общения и персонажей; — обработку пользовательских запросов и управление сессиями; — интеграцию модели с пользовательским приложением; — настройку поведения и системных промптов. В качестве основной модели используется Qwen3.6-35B-A3B. Проект позволил получить практический опыт не только работы с LLM API, но и самостоятельного развертывания, настройки и эксплуатации генеративной модели. Результат: создан работающий AI-сервис с текстовым и голосовым взаимодействием, работающий на собственной LLM-инфраструктуре.

Telegram-бот расписания РУТ (МИИТ) Разработал Telegram-бота для студентов Российского университета транспорта, чтобы упростить доступ к учебному расписанию и информации о занятиях. В боте реализовал: — просмотр расписания своей группы; — поиск расписания преподавателей; — поиск одногруппников и студентов; — быстрый доступ к информации прямо из Telegram; — обработку пользовательских запросов и навигацию по данным; — автоматическое обновление информации без необходимости вручную искать расписание на сайте университета. Проект создавался как практический сервис под реальную потребность студентов и использовался не как учебный прототип, а как рабочий инструмент. Результат: пользователи получили более быстрый и удобный способ получать расписание и связанную учебную информацию через Telegram. Стек: Python, aiogram, Telegram Bot API, REST/API-интеграции, асинхронное программирование, Git.

root VPN — собственный сервис защищённого интернет-доступа Разработал и развернул сервис для автоматизированного предоставления VPN-доступа пользователям. В рамках проекта реализовал: — backend для управления пользователями и подписками; — автоматическую выдачу и управление VPN-конфигурациями; — Telegram-бот для взаимодействия с пользователями; — управление серверной инфраструктурой; — автоматизацию подключения и обслуживания пользователей; — хранение данных и учет активных подписок; — мониторинг состояния сервиса; — интеграцию клиентской части с backend и инфраструктурой. Проект включает не только разработку приложения, но и практический опыт развёртывания и эксплуатации собственного сетевого сервиса: backend, серверы, базы данных, автоматизация и поддержка production-инфраструктуры. Результат: создан работающий сервис, позволяющий пользователю получить и использовать VPN-доступ без ручной настройки со стороны администратора

StoryCheck — Telegram Mini App с backend-инфраструктурой и платежными интеграциями Разработал full-stack сервис с Telegram Mini App, ботом и отдельным backend для обработки пользовательских запросов и фоновых задач. В проекте реализовал: — backend на FastAPI; — асинхронную обработку задач через Celery; — PostgreSQL и Redis; — Telegram Mini App на React; — real-time обновления через WebSocket; — авторизацию и взаимодействие с Telegram; — четыре платежные интеграции: Telegram Stars, TON Connect, Robokassa и Stripe; — Docker-контейнеризацию; — CI/CD через GitHub Actions; — логирование, обработку ошибок и тестирование; — аналитику пользовательской активности и платежей. Проект показывает мой опыт разработки не отдельного скрипта, а полноценного веб-сервиса: frontend, backend, базы данных, очереди задач, платежи, интеграции и инфраструктура развертывания. Стек: Python, FastAPI, Celery, PostgreSQL, Redis, React, WebSocket, Docker, GitHub Actions, REST API, Telegram API.

Beautybook — SaaS-платформа для автоматизации записи и управления клиентами в бьюти-сфере Разработал полноценный сервис, который автоматизирует путь клиента от записи до напоминания и оплаты. Изначально задача была локальной: убрать хаос из личных переписок мастера и перенести запись клиентов в Telegram. В процессе решение выросло в самостоятельную платформу, которой могут пользоваться разные мастера. Реализовал: — онлайн-запись через веб и Telegram; — управление расписанием и свободными слотами; — перенос и отмену записей; — автоматические напоминания; — приём оплат; — личный кабинет мастера; — статистику и аналитику; — интеграции с календарями; — AI-помощника для клиентов и мастеров; — мультиарендную архитектуру для работы нескольких мастеров в одной системе; — backend, API, базу данных, frontend и инфраструктуру развертывания. Стек: Python, FastAPI, PostgreSQL, Redis, SQLAlchemy, React, Docker, REST API, Telegram Bot API, AI/LLM. Результат: ручной процесс записи и ведения клиентов был превращён в автоматизированный SaaS-сервис, который можно масштабировать под большое количество мастеров и использовать как полноценный коммерческий продукт. Проект показывает мой опыт не только в написании ботов, но и в проектировании архитектуры, backend-разработке, интеграциях, работе с данными, платежами и запуске готового продукта.

Я делал двусторонний обмен МойСклад и AmoCRM для оптовых продаж: сделка в CRM порождала заказ покупателя и отгрузку в учёте, а факты оплаты и отгрузки возвращали стадию сделки. Менеджер не вбивал номенклатуру дважды. Я написал коннектор к обоим API: справочник контрагентов и номенклатуры, сопоставление SKU и кастомных полей AmoCRM, создание/обновление заказа в МойСклад по смене стадии. Источник правды по остаткам — МойСклад; в сделку писал доступность и резерв, чтобы не продавали «с пустой полки». Я программировал идемпотентный обмен документов: заказ, счёт, отгрузка, возврат. Повтор webhook не создавал второй заказ; внешние id хранил в обеих системах. Конфликты (менеджер поправил сумму в CRM, кладовщик уже отгрузил в учёте) закрывал правилами: после отгрузки финансовые поля из CRM не перезаписывают учёт. Я собрал очередь синхронизации с ретраями, разбором 429/5xx, батчами справочников (тысячи SKU) и инкрементальным diff, а не полной выгрузкой каждую ночь. Расхождения ловил сверкой: сделка без заказа, отгрузка без стадии «успешно реализовано». Я вывел админ-лог обмена и ручной «переотправить документ». Стек: Python, AmoCRM REST, МойСклад JSON API, PostgreSQL, Redis, Docker. NDA: юрлицо и аккаунты не публикуются.