API — это не просто интерфейс, а полноценный продукт с живыми пользователями

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

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

Меня зовут Лев Савельев, я старший менеджер по продукту Ozon Seller API. В этой статье расскажу, как мы развиваем Seller API как продукт, с какими вызовами столкнулись, какие ошибки сделали и чему научились, и как вся работа связана с экосистемой Ozon — порталом dev.ozon.ru и существующим Магазином приложений для селлеров.

Две аудитории: разработчики и пользователи — почему это важно

Распространённое заблуждение — считать, что API нужен только разработчикам. На самом деле, у нас две главные аудитории, и обе из которых требуют разного подхода:

• Разработчики — они интегрируются с API, хотят понятную документацию, стабильность, понятные ошибки и их решение, быстрый отклик и поддержку;

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

При развитии такого продукта нельзя акцентировать внимание на решение задач только для одних пользователей, необходимо искать баланс. Примечательно, что разработчики могут создавать собственные рыночные продукты или работать в крупных компаниях-продавцах, что практически стирает границы между аудиториями «разработчики» и «продавцы». Это, конечно, не всё, и аудитории ещё сегментируются. Разработчики, работающие над интеграцией с продавцом, и разработчики, создающие свой продукт на основе API для продавцов, имеют свои нюансы. Продавцы бывают крупные и мелкие, для них, как правило, приоритетен разный функционал. Для продавцов из других стран изменения в бизнес-процессах накладывает законодательство.

Для разработчиков мы стараемся делать понятную, структурированную и максимально прозрачную документацию, развиваем нашу платформу и отлаживаем механизм мониторинга качества.

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

Помимо готовых решений, естественно, мы развиваем API как продукт, также исходя из потребностей самих продавцов. Условно, необходимо автоматизировать поставки на склады FBO или же ответы на вопросы покупателей, мы «упаковываем» этот функционал в методы API, не забывая про консистентность названия полей, типов пагинации, лимиты и фильтры.

Кроме того, Seller API развивается в рамках проекта «Магазин приложений». Мы стремимся к тому, чтобы компании, разрабатывающие продукты на базе Seller API, могли предлагать свои решения конечным пользователям. Таким образом, мы создаём продукт, который способствует прямому взаимодействию двух наших аудиторий, используя Seller API в качестве основного инструмента.

Как мы развиваем Seller API в Ozon

Развитие внешнего API в Ozon представляет собой интересный процесс, учитывая, что в компании насчитывается несколько тысяч сервисов со своей логикой и спецификой.

Реализация новых или единичных методов может осуществляться по двум основным направлениям.

Направление 1. Инициатива команды Seller API

• Мы постоянно собираем обратную связь от крупных и мелких продавцов, при этом ключевое значение имеет частота обращений;

• На основе этой обратной связи и обращений в службу поддержки формируется наш внутренний бэклог;

• Далее мы ищем команду менеджеров по продукту, отвечающую за нужный нам функционал, и приоритизируем задачу;

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

• В любом случае вне зависимости от необходимости доработок в сервисе, мы согласовываем «рейт-лимиты» и контракты;

• Подготавливаем аналитику;

• Существует процесс груминга этой аналитики (согласование решения с нашей разработкой);

• Оцениваем трудозатраты;

• Приоритизируем задачу внутри нашей команды;

• Аналитик также готовит задачи для команды технических писателей по созданию документации;

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

Направление 2. Инициатива бизнес-заказчика или внутреннего сервиса

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

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

Вне зависимости от направления, релизная политика одинакова — каждый новый метод или новая версия метода выпускается в разделе «Бета». URL метода при этом остаётся таким же, как и у продуктовой версии. Однако потребителям следует учитывать, что сам контракт может быть изменён (хотя это происходит редко). Мы используем бета-версию как тестовый период для выявления пограничных случаев.

Push-модель в Seller API: почему это важно

Ранее интеграции часто работали только на основе периодического опроса (polling) — когда клиентские приложения регулярно «спрашивали» сервер о новых данных. Это создавало излишнюю нагрузку и задержки.

Мы активно развиваем push-модель, когда события (новый заказ, изменение статуса, возврат и прочее) сразу отправляются в сторонние системы через webhook. Это позволяет:

• снизить нагрузку на API и серверы;

• уменьшить задержки — события обрабатываются моментально;

• повысить стабильность и качество интеграций;

• и более рационально пользоваться связкой Push-сервиса и Seller API.

Push-модель развивается, но уже приносит значительные улучшения в стабильности и отзывчивости систем.

Метрики, на которые мы ориентируемся

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

• Процент ошибок (Failure rate): количество неудачных запросов и ошибок — это критически важно для стабильности.

• Время безотказной работы (Uptime): сколько времени API работает без сбоев.

• Задержка отклика (Latency): время, которое требуется API для ответа.

• Количество активных приложений и интеграций: сколько приложений и интеграций активно используют наш API.

• Процент ошибок по конкретным конечным точкам (Error rate по конкретным эндпоинтам): помогает выявлять проблемные зоны в API.

• Время подключения нового разработчика (time to first call): насколько быстро разработчики могут начать пользоваться API.

• Валовый объём продаж продавцов (GMV продавцов): объём продаж, который проходит через интеграции с нашим API. Это самая важная метрика для продавцов, хотя есть и другие метрики покрытия.

Эти метрики позволяют нам видеть как реальные бизнес-эффекты, так и технологические проблемы.

Монетизация API: сложный баланс

API сам по себе — это интерфейс, и монетизировать его напрямую сложно. 

Как мы смотрим на монетизацию:

• Прямо сейчас Seller API не приносит прямой выручки — доступ к нему бесплатен для разработчиков и продавцов. Исключение — несколько групп методов, которые доступны только для премиум-подписки, например, методы чатов и отзывов. Однако это не прямая монетизация, а скорее способ ограничить доступ к сенситивной информации.

• У магазина приложений есть возможность внедрить монетизацию, но мы её не используем, так как хотим дать лучший сервис продавцам и разработчикам, чтобы Ozon рассматривался как ультимативная и максимально функциональная площадка для торговли. Разработчики могут предлагать платные сервисы, а продавцы — напрямую оплачивать подписки и услуги.

• Есть ещё один путь – премиальные тарифы с расширенными SLA и лимитами, но это требует очень аккуратного подхода, чтобы не ухудшить опыт пользователей.

Как мы выстраиваем экосистему продуктов

Магазин приложений — витрина решений на Ozon

Как это работает.

1. API как фундамент 

Весь Магазин приложений построен на базе Seller API. Это означает, что разработчики используют те же инструменты и методы, что и мы внутри компании, обеспечивая единый стандарт взаимодействия решений с системами Озон. Мы предоставляем обширную документацию, проектируем SDK, чтобы минимизировать порог входа.

2. Двусторонняя выгода

• Для продавцов Магазин приложений предлагает широкий спектр готовых решений: от инструментов для автоматизации маркетинга и управления запасами до сложных аналитических систем и интеграций с другими сервисами. Продавцы могут легко найти и установить приложения, которые помогут им оптимизировать бизнес-процессы, увеличить продажи и улучшить взаимодействие с клиентами, не прибегая к дорогостоящим индивидуальным разработкам.

• Для разработчиков Магазин приложений открывает доступ к огромной аудитории наших продавцов. Разработчики могут монетизировать свои решения, предлагая платные подписки (у большинства приложений есть ещё пробный бесплатный тариф). Это создаёт мощный стимул для создания инновационных и полезных приложений, что, в свою очередь, обогащает функционал Seller API.

3. Контроль качества и безопасность 

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

4. Вовлечение сообщества

Мы активно работаем над созданием сообщества разработчиков вокруг нашего API и Магазина приложений. Проводятся воркшопы, вебинары, создаются статьи и кейсы для обмена опытом и идеями. Это способствует не только развитию API, но и появлению новых, востребованных решений.

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

Ozon for developers — центр управления интеграциями

Платформе для разработчиков в следующем году исполнится уже 3 года! Мы продолжаем поддерживать её всеми возможными способами — выкатываем полезные обновления, добавляем важный функционал и, самое главное, постоянно наполняем её контентом, в большинстве случаев уникальным. На платформе находится и Личный кабинет разработчика, позволяющий управлять приложениями, которые разработчики разместили в Магазине приложений. 

Каналы в Telegram

Когда экосистема уже функционирует, присутствие на всех платформах, включая Telegram, становится необходимым. У команды Seller API есть два ключевых канала: канал push-уведомлений об обновлениях Seller API и канал Ozon for Dev. В последнем мы делимся новостями, касающимися API Ozon, и взаимодействуем с нашим сообществом разработчиков. Ошибки и баги часто обнаруживаются, когда несколько разработчиков обращаются к нам в чат с сообщением: «Метод X перестал работать, исправьте!». Это позволяет оперативно вносить исправления в наши системы.

Заключение

API перестали быть просто техническим интерфейсом и превратились в полноценный продукт, который может стать ключевым конкурентным преимуществом для компаний. Пример Ozon Seller API демонстрирует, как комплексный подход к разработке и поддержке API, ориентированный на удобство как разработчиков, так и конечных пользователей (продавцов), позволяет создавать мощные инструменты для автоматизации и масштабирования бизнеса.