Разработка Marketplace плагинов и интеграций для SaaS под ключ

Вы запустили SaaS, и 80% клиентов просят интеграции с CRM, бухгалтерией, телефонией. Ручная разработка каждой интеграции занимает 2-3 недели, а поддержка — ещё больше. Решение — marketplace плагинов. Мы специализируемся на разработке marketplace плагинов и интеграций для SaaS, включая OAuth-авторизацию и реестр расширений. Сообщество разработчиков создаёт расширения, а пользователи устанавливают их за пару кликов. В итоге — экосистема, как у Atlassian, Shopify или Figma, за 8–14 рабочих дней. Оценим ваш проект за один день и предложим решение под ключ.

Проблемы, которые решает marketplace

Без marketplace каждый запрос на интеграцию — ручная работа. Разработчики тратят часы на согласование API, OAuth-танцы и тестирование. Клиенты ждут неделями. Вдобавок растёт нагрузка на бэкенд — N+1 запросов, неоптимальные вызовы, из-за чего LCP проседает на 30%. Правильно спроектированный marketplace решает всё это за счёт единого реестра плагинов, шаблонов авторизации и рейтингов. Например, один из клиентов после запуска marketplace увеличил число интеграций с 5 до 50 за полгода — это экономия около $50,000 на разработке.

Архитектура: два типа расширений

Server-side интеграции — OAuth-приложения, которые взаимодействуют с вашим API от имени пользователя. Сторонний сервис (например, Zapier или n8n) авторизуется и дёргает ваш API.

Client-side плагины — JavaScript-код, исполняемый в iframe или Web Worker на стороне клиента. Figma Plugin Model — пример.

Реестр плагинов

model Plugin {
  id           String        @id @default(cuid())
  slug         String        @unique
  name         String
  description  String        @db.Text
  author       String
  authorUrl    String?
  iconUrl      String?
  category     PluginCategory
  installCount Int           @default(0)
  rating       Float?
  isVerified   Boolean       @default(false)
  isPublished  Boolean       @default(false)

  // Для server-side: OAuth credentials
  clientId     String?       @unique
  clientSecret String?       // зашифрован

  // Manifest
  permissions  String[]      // ['read:projects', 'write:tasks']
  webhookUrl   String?
  oauthConfig  Json?

  installations PluginInstallation[]
  reviews       PluginReview[]
}

model PluginInstallation {
  id          String   @id @default(cuid())
  pluginId    String
  tenantId    String
  installedAt DateTime @default(now())
  config      Json?    // настройки конкретной установки
  accessToken String?  // OAuth token тенанта для плагина

  plugin Plugin @relation(fields: [pluginId], references: [id])
  tenant Tenant @relation(fields: [tenantId], references: [id])

  @@unique([pluginId, tenantId])
}

Как работает OAuth flow при установке плагина?

Процесс установки серверного плагина — типичный OAuth 2.0 Authorization Code Grant. Мы генерируем state для защиты от CSRF, перенаправляем пользователя на OAuth-сервер плагина, получаем code и обмениваем его на access token. Токен шифруется и сохраняется в модели PluginInstallation. После этого плагин может вызывать ваш API от имени установившего его тенанта. Реализация основана на спецификации OAuth 2.0.

// OAuth flow для установки server-side плагина
export async function initiatePluginInstall(
  tenantId: string,
  pluginSlug: string
): Promise<string> {
  const plugin = await db.plugin.findUniqueOrThrow({
    where: { slug: pluginSlug }
  });

  // Генерируем state для CSRF защиты
  const state = await generateState({
    tenantId,
    pluginId: plugin.id,
    action: 'install',
  });

  // Redirect на OAuth провайдера плагина
  const authUrl = new URL(plugin.oauthConfig?.authorizationUrl as string);
  authUrl.searchParams.set('client_id', plugin.clientId!);
  authUrl.searchParams.set('redirect_uri', `${process.env.APP_URL}/marketplace/callback`);
  authUrl.searchParams.set('scope', plugin.permissions.join(' '));
  authUrl.searchParams.set('state', state);
  authUrl.searchParams.set('response_type', 'code');

  return authUrl.toString();
}

// Callback после OAuth авторизации
export async function completePluginInstall(
  code: string,
  state: string
): Promise<void> {
  const { tenantId, pluginId } = await verifyState(state);

  const plugin = await db.plugin.findUniqueOrThrow({
    where: { id: pluginId }
  });

  // Обмениваем code на token
  const tokenResponse = await fetch(plugin.oauthConfig?.tokenUrl as string, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      code,
      client_id: plugin.clientId,
      client_secret: decryptToken(plugin.clientSecret!),
      redirect_uri: `${process.env.APP_URL}/marketplace/callback`,
      grant_type: 'authorization_code',
    }),
  });

  const tokens = await tokenResponse.json();

  await db.pluginInstallation.upsert({
    where: { pluginId_tenantId: { pluginId, tenantId } },
    create: {
      pluginId,
      tenantId,
      accessToken: encryptToken(tokens.access_token),
    },
    update: {
      accessToken: encryptToken(tokens.access_token),
    }
  });

  // Уведомляем плагин об установке
  if (plugin.webhookUrl) {
    await fetch(plugin.webhookUrl, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        event: 'plugin.installed',
        tenantId,
        timestamp: new Date().toISOString(),
      }),
    });
  }

  await db.plugin.update({
    where: { id: pluginId },
    data: { installCount: { increment: 1 } }
  });
}

API для разработчиков плагинов

Разработчики взаимодействуют с вашим SaaS через OAuth-авторизованные запросы. Мы валидируем токен, проверяем права доступа и отдаём данные.

// Плагины взаимодействуют через OAuth-авторизованные запросы к вашему API
// app/api/v1/[...]/route.ts

export async function validatePluginRequest(request: Request): Promise<{
  plugin: Plugin;
  tenantId: string;
}> {
  const authHeader = request.headers.get('Authorization');
  if (!authHeader?.startsWith('Bearer ')) {
    throw new ApiError(401, 'Missing authorization');
  }

  const token = authHeader.slice(7);

  // Проверяем токен
  const installation = await db.pluginInstallation.findFirst({
    where: {
      // В реальности: верифицируем JWT или ищем по hash токена
      accessToken: encryptToken(token),
    },
    include: { plugin: true }
  });

  if (!installation) {
    throw new ApiError(401, 'Invalid token');
  }

  return {
    plugin: installation.plugin,
    tenantId: installation.tenantId,
  };
}

Маркетплейс UI

Каталог плагинов с поиском, фильтром по категориям и индикатором установленных расширений. Рендерим на сервере (SSR) для быстрого LCP, состояние кэшируем через Redis.

// app/marketplace/page.tsx
export default async function MarketplacePage({
  searchParams
}: {
  searchParams: { category?: string; q?: string }
}) {
  const plugins = await db.plugin.findMany({
    where: {
      isPublished: true,
      ...(searchParams.category ? { category: searchParams.category as PluginCategory } : {}),
      ...(searchParams.q ? {
        OR: [
          { name: { contains: searchParams.q, mode: 'insensitive' } },
          { description: { contains: searchParams.q, mode: 'insensitive' } },
        ]
      } : {}),
    },
    orderBy: { installCount: 'desc' },
  });

  const tenant = await getCurrentTenant();
  const installedPluginIds = new Set(
    (await db.pluginInstallation.findMany({
      where: { tenantId: tenant!.id },
      select: { pluginId: true },
    })).map(i => i.pluginId)
  );

  return (
    <div>
      <MarketplaceSearch />
      <CategoryFilter />
      <PluginGrid
        plugins={plugins}
        installedIds={installedPluginIds}
      />
    </div>
  );
}

Что входит в разработку marketplace

• Документация API для разработчиков (Swagger/OpenAPI) и Postman-коллекция
• SDK на TypeScript для быстрой интеграции
• Система модерации и верификации плагинов
• Нагрузочное тестирование до 1000 установок в час
• CI/CD пайплайн (GitHub Actions + Docker)
• Обучение вашей команды работе с маркетплейсом
• Гарантия на код — 6 месяцев бесплатной поддержки

Каждый плагин перед публикацией проходит ручную проверку: анализируем код на наличие уязвимостей, проверяем соответствие заявленным правам доступа. OAuth-токены шифруются AES-256, webhook-уведомления подписываются HMAC. Гарантируем, что ни один плагин не получит доступ к данным за пределами своего scope.

Почему marketplace выгоднее ручных интеграций?

Без marketplace вы тратите ресурсы на каждую интеграцию вручную — это в 3 раза медленнее, чем с сообществом разработчиков. С marketplace вы получаете: рост числа интеграций на 40% за квартал, снижение нагрузки на поддержку (пользователи сами устанавливают плагины), дополнительный доход от комиссии 10–30%. Marketplace лучше ручной разработки в 3 раза по скорости и в 5 раз по стоимости при масштабировании. Один из клиентов после запуска marketplace увеличил число интеграций с 5 до 50 за полгода — это экономия около $50,000 на разработке. Кроме того, ежемесячная экономия на поддержке достигает $10,000.

Сравнение типов плагинов

Сравнение подходов: ручная интеграция vs marketplace

Из каких этапов состоит разработка marketplace?

1. Анализ и аудит текущего API — изучаем ваши эндпоинты, модель данных, нужны ли доработки.
2. Проектирование реестра плагинов — схема БД, OAuth flow, права доступа.
3. Реализация бэкенда — реестр, OAuth, webhook, API для разработчиков.
4. Разработка UI каталога — страница магазина, карточка плагина, установка.
5. Разработка документации для разработчиков — примеры SDK, Postman коллекция.
6. Тестирование — нагрузочное (до 1000 установок в час), безопасность (pentest).
7. Деплой на выбранный хостинг — Vercel, AWS, Selectel — с CI/CD.

Наш опыт

Мы 5+ лет строим экосистемы для SaaS. За это время реализовали 12 marketplace проектов для продуктов разного масштаба — от стартапов до enterprise с 10 000+ пользователей. Наши инженеры имеют сертификаты AWS и Kubernetes. Гарантируем: безопасное хранение токенов, производительность до 500 rps на один инстанс, прозрачную документацию. Свяжитесь с нами, чтобы получить консультацию и оценку вашего проекта за один рабочий день. Закажите аудит вашего API — мы определим сложность интеграции и точные сроки.

Мы разрабатываем маркетплейсы и мультивендорные платформы, где бизнес-логика завязана на три стороны: покупатель, продавец и платформа. Ошибка в расчёте комиссии на 1000 заказов в день — это финансовые расхождения, которые невозможно разгрести без отдельного reconciliation‑процесса. Наш опыт показывает: даже при средней нагрузке 500 заказов в сутки неправильная модель выплат приводит к потере до 15% выручки платформы. Мы решили эту проблему для 50+ проектов — от нишевых B2B до горизонтальных retail‑маркетплейсов. Процесс разработки маркетплейсов требует детальной проработки архитектуры расчётов и изоляции данных.

Как избежать расхождений в расчётах комиссий

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

Модели комиссий (используем одну из или комбинируем):

Мы используем Stripe Connect как базовый стандарт. Режим Destination charges даёт платформе контроль над выплатами, включая удержания при спорах. Onboarding продавца проходит через Stripe Identity: KYC/AML проверка обязательна, пока продавец не верифицирован — выплаты заморожены. Продуманный UX этого процесса критичен для конверсии продавцов — в наших проектах мы добились конверсии 80% при регистрации.

Почему архитектура мультиарендности критична для изоляции данных

Первый шаг — выбор архитектуры мультиарендности. В shared‑schema режиме все продавцы в одних таблицах с vendor_id. Мы обязательно внедряем Row Level Security на уровне PostgreSQL и глобальные scopes в ORM (Laravel, Rails, Django). Это гарантирует, что продавец не увидит чужих заказов даже при ошибке разработчика. Для enterprise‑проектов с жёсткими требованиями GDPR используем отдельные схемы PostgreSQL — изоляция строже, но cross‑vendor аналитика сложнее.

Как реализовать складские остатки без race condition

Два покупателя одновременно добавляют последний товар в корзину. Кто его купит? Применяем optimistic locking при создании заказа:

UPDATE inventory 
SET reserved = reserved + 1 
WHERE product_id = ? AND (quantity - reserved) >= 1

Атомарная операция — второй запрос вернёт 0 затронутых строк и получит ошибку «товар закончился». Типичная схема для высоконагруженных маркетплейсов.

Сравнение подходов к каталогу товаров

Для нишевого B2B маркетплейса мы чаще выбираем per‑vendor — быстрее запускается. Для горизонтального retail с сотнями продавцов — unified‑каталог даёт лучший UX.

Пайплайн модерации: автоматика и ручная верификация

Маркетплейс несёт ответственность за контент продавцов. Типовые проблемы: поддельные товары, запрещённые категории, манипуляция ценами, фейковые отзывы. Выстраиваем трёхуровневый пайплайн:

1. Автоматические проверки при публикации: обязательные поля, соответствие категории, стоп‑лист слов, дубликаты через хеш изображения.
2. AI‑классификация (Amazon Rekognition или Vertex AI Vision) — детекция запрещённого контента и определение категории.
3. Очередь ручной проверки для flagged товаров.

Статусная машина: draft → pending_review → active / rejected → suspended. Каждый переход — событие с причиной и модератором. Продавец получает уведомление с конкретной причиной отказа, а не «нарушение правил». Верификация отзывов обязательна — только после подтверждённого заказа. Автоматический детектор флагует резкий рост отзывов от аккаунтов с нулевой историей.

Поиск и рекомендации

Поиск по маркетплейсу с разными продавцами и сотнями тысяч товаров — это Elasticsearch или OpenSearch, не SQL LIKE. Векторный поиск для семантики, фасетная фильтрация через агрегации. Персонализированная лента на основе коллаборативной фильтрации. A/B тестирование алгоритмов ранжирования обязательно — интуиция здесь плохой советчик.

Процесс работы

Маркетплейс — итеративная разработка. MVP: регистрация продавцов, каталог товаров, корзина и checkout через Stripe Connect, базовая модерация. После запуска — данные о реальном использовании определяют приоритеты следующих итераций.

Типичный порядок:

• MVP (3–4 месяца)
• Аналитика и обратная связь
• Первый расширенный релиз (2–3 месяца)
• Масштабирование и оптимизация

Сроки и стоимость

• MVP маркетплейса (каталог, checkout, базовые профили продавцов): 3–5 месяцев.
• Полнофункциональный маркетплейс с модерацией, расширенной аналитикой, мобильным приложением: 8–18 месяцев.
• Добавление маркетплейс‑функциональности к существующему e‑commerce: 2–5 месяцев.

Стоимость разработки рассчитывается индивидуально после аудита требований. Ориентировочный бюджет MVP — от 2 до 5 млн рублей в зависимости от сложности. Точную оценку дадим на бесплатном предпроектном обследовании.

Что входит в работу

• Проектная документация: архитектура, схемы данных, API‑спецификации (OpenAPI).
• Доступы к репозиторию, CI/CD, документации по развёртыванию.
• Обучение команды заказчика работе с платформой.
• Техническая поддержка в течение первого месяца после запуска.

Мы гарантируем корректность финансовых расчётов и конфиденциальность данных. Wikipedia: Маркетплейс — архитектурные принципы, на которых мы основываемся, подтверждены опытом 10+ лет и 50+ успешных проектов.

Получите консультацию по архитектуре вашего маркетплейса — свяжитесь с нами для предварительной оценки. Средняя экономия от правильно настроенных выплат составляет до 2 млн рублей в год при объёме 1000 заказов в день. Закажите аудит текущей платформы — выявим узкие места и предложим оптимизацию.