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

Я делал интеграцию АТС / коллтрекинга с AmoCRM: входящий и исходящий звонок сразу попадал в карточку контакта, создавалась задача или сделка, подтягивалась запись разговора. Менеджер не искал номер вручную и не терял пропущенные. Я написал приёмник событий АТС (webhook + нормализация payload разных провайдеров) и слой сопоставления: номер → контакт. Телефоны приводил к единому формату (E.164 / 7XXXXXXXXXX), отрезал добавочные и «мусор» из SIP. Если контакта нет — создавал, если есть несколько — выбирал по правилам (последняя открытая сделка, ответственный, не дубль). Я реализовал логику пропущенных и повторных звонков: не плодить сделку на каждый гудок, склеивать сессию, ставить задачу ответственному, эскалировать, если никто не взял за N минут. Для исходящих подставлял ответственного из AmoCRM, чтобы коллтрекинг не вешал звонок на «общую линию». Я отдельно программировал загрузку записей разговоров: ссылка в примечании сделки, права доступа, повтор при 404 у АТС, таймауты. Упёрся в лимиты API AmoCRM и АТС — очереди, идемпотентные ключи по call_id, чтобы один звонок не создавал десять заметок. Я добавил журнал: call_id, направление, длительность, найденный контакт, созданная сделка, ошибка маппинга. Стек: Python, FastAPI, AmoCRM REST, webhooks АТС, Redis, PostgreSQL. NDA: провайдер телефонии и аккаунт CRM не публикуются.

Я делал двустороннюю интеграцию интернет-магазина на WooCommerce с AmoCRM: заказ на сайте становился сделкой в воронке, смена стадии в CRM возвращала статус заказа в магазин. Источник правды по оплате — WooCommerce, по работе менеджера — воронка AmoCRM. Я написал синхронизирующий сервис, а не набор «webhook → создай сделку». Очередь задач, идемпотентность по order_id / deal_id, дедупликация контактов по нормализованному телефону и email. Повторная оплата или двойной webhook не плодили вторую сделку. Я спроектировал маппинг сущностей: заказ → сделка, позиции → состав и примечание, покупатель → контакт + компания, статусы оплаты/доставки → стадии воронки. Кастомные поля AmoCRM (состав, трек-номер, способ доставки, UTM) заполнял через API, без ручного копирования менеджером. Я закрыл гонки и конфликты: если менеджер двинул сделку, а покупатель в ту же секунду сменил адрес на сайте — применял правила merge (какие поля пишет магазин, какие только CRM). Для лимитов AmoCRM API сделал backoff, батчи и повтор упавших запросов; битые события уходили в dead-letter с логом для разбора. Я повесил webhooks с обеих сторон и fallback-опрос (cron), если webhook потерялся. Написал журнал обмена: что ушло, что пришло, код ответа, повтор. Стек: PHP/Python, WooCommerce REST, AmoCRM REST, очереди, PostgreSQL. NDA: магазин и аккаунт CRM не публикуются.

Разработка Python-решений для автоматического обмена данными между внешними сервисами, программами и внутренними таблицами. API позволяет получать и передавать данные напрямую между системами без постоянного ручного копирования информации. В рамках подобных задач могут выполняться: подключение к REST API; отправка запросов к внешнему сервису; получение структурированных данных; обработка JSON-ответов; проверка структуры и значений; преобразование полученной информации; объединение данных из нескольких источников; выгрузка результатов в Excel / CSV; формирование таблиц и отчётов; регулярное автоматическое обновление; передача обработанных данных в другую систему. Такой подход подходит для работы с каталогами, заказами, клиентами, остатками, статусами, отчётами и другими данными, доступными через API. Решение может использоваться как отдельный Python-скрипт или стать частью более крупной программы, Telegram-бота, системы учёта или рабочего процесса автоматизации. Технологии: Python, REST API, JSON, requests, pandas, Excel / CSV. Результат — воспроизводимый автоматический обмен данными вместо постоянной ручной загрузки и переноса информации.

Подключил один движок к шести средам, у каждой свой формат обмена. Главное тут не количество. При сверке с первоисточниками выяснилось, что две интеграции молча не работали. Одна отправляла ответ, который принимающая сторона отвергала целиком из-за лишних полей. Вторая слушала не то имя. Обе были написаны строго по документации и снаружи выглядели рабочими. С тех пор считаю интеграцию сделанной не когда код написан по докам, а когда проверена на реальном ответе.

Разработал и развернул платформу из пяти изолированных MCP-сервисов для Gmail, Calendar, Drive, Sheets и Docs. Каждый сервис работает отдельным процессом и владеет только своей частью доступа к Google Workspace. Реализовано: • 55 инструментов для почты, календаря, файлов, таблиц и документов; • отдельные endpoint, состояние OAuth, набор разрешений, учётные данные и реестр инструментов для каждого сервиса; • OAuth 2.1 с PKCE, привязкой токена к защищённому ресурсу и ротацией refresh-токенов; • обнаружение повторного использования refresh-токена с отзывом всей связанной цепочки; • проверка фактических разрешений Google и закрытый отказ при несовпадении сервиса или ресурса; • управляемые загрузки файлов, аудит операций и безопасные границы ошибок провайдера; • пять экземпляров systemd за единым публичным HTTPS-контуром Nginx. Проверка: 1644 автоматизированных теста, Ruff и MyPy без ошибок. Результат: сбой или разрешение одного Google-сервиса не расширяет доступ к остальным четырём. Учётные данные Google не передаются MCP-клиенту и остаются внутри управляемой среды. Технологии: Python 3.14, MCP Python SDK, Starlette, Pydantic, OAuth 2.1, Google API Python Client, systemd, Nginx.

Разработал и внедрил автоматический пайплайн загрузки данных Wildberries API в PostgreSQL для аналитики и бизнес-процессов. Архитектура построена по схеме RAW → STG → MART по принципу «1 метод API = 1 RAW = 1 STG». В RAW сохраняется полный ответ API без потери исходных данных, в STG выполняется распаковка и нормализация всех полученных полей, а в MART формируется единая накопительная витрина заказов с одной строкой на заказ. Подключил методы получения новых и текущих заказов, статусов, данных курьера и стикеров. Для незавершённых заказов реализовал повторный опрос: после получения финального статуса заказ автоматически исключается из дальнейших запросов. Настроил общий процесс загрузки и автоматический запуск каждые 5 минут. Проверил соответствие ответов API слоям RAW/STG и итоговой MART-витрине, включая корректную обработку отсутствующих значений. Результат: актуальные данные Wildberries поступают в PostgreSQL без ручных выгрузок и готовы для отчётности, аналитики и дальнейших интеграций. Стек: REST API, PostgreSQL, SQL, ETL, RAW/STG/MART, cron. Иллюстрации обезличены, внутренние идентификаторы и данные заменены демонстрационными.

Выгрузка заказов через API падала на середине с ошибкой «cannot read properties of undefined». В логе была только строка падения, причины в ней нет. Оказалось, у одного заказа не было покупателя — код молча предполагал, что покупатель есть всегда. Такие дыры находятся не чтением кода, а прогоном на настоящих данных. Починка: пустой случай обрабатывается и попадает в отчёт отдельной пометкой, а не роняет выгрузку. Из 3 заказов выгрузились 3, ни один не пропущен.

Собственное native macOS-приложение для управления инженерным AI-агентом Ashitaka. Приложение объединяет работу с проектами, задачами, чатами, тестами, approvals, диагностикой и результатами изменений в одном интерфейсе. Реализованы: • native интерфейс на SwiftUI; • подключение к локальному canonical runtime; • работа с репозиториями и проектами; • просмотр задач и статусов выполнения; • подтверждение изменений с просмотром точного patch; • запуск тестов и отображение verification; • benchmark/operator interface; • восстановление состояния после restart; • безопасное разделение UI и агентной логики. Приложение используется как операторская оболочка для локальной разработки, диагностики и контролируемого выполнения задач AI-агентом.

Собственный engineering-кейс по диагностике и исправлению ошибок в проектах на Python, JavaScript/TypeScript, Java, Go и Rust. Процесс построен как полный цикл разработки: анализ задачи и репозитория → локализация причины → подготовка минимального patch → согласование изменения → контролируемое применение → запуск нативных тестов и проверка результата. В рамках проекта реализованы: • анализ структуры и исходного кода репозитория; • поиск root cause и связанных файлов; • работа с несколькими языками программирования; • генерация минимальных исправлений; • просмотр patch перед применением; • безопасное применение изменений; • запуск Python, Node, Java, Go и Rust verification; • защита от повторного выполнения изменений; • сохранение истории проверок и результатов. Такой подход применяется к bugfix, regression repair, падающим тестам, API-интеграциям и доработке существующих проектов.

Собственный проект — Ashitaka, автономный AI-агент для разработки, диагностики и исправления программного обеспечения. Система анализирует репозитории, локализует причины ошибок, формирует исправления и проверяет результат тестами. Для потенциально опасных изменений используется отдельный контур согласования: оператор видит точный patch до применения, после чего изменение выполняется контролируемо и проходит обязательную верификацию. Реализованы: • работа с Python, JavaScript/TypeScript, Java, Go и Rust; • интеграция с несколькими LLM-провайдерами; • анализ структуры и исходного кода репозитория; • поиск ошибок и regression-проблем; • генерация и проверка patch; • Approval / Safe Action для изменений; • автоматический запуск тестов и Repository Verification; • защита от повторного выполнения изменений; • native macOS-приложение для управления агентом. Проект используется как инженерная платформа для автоматизации bugfix, API/AI-интеграций, анализа существующего кода и других задач разработки.