Розробка 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 зачеплених рядків та отримає помилку «товар закінчився». Типова схема для високонавантажених маркетплейсів.

Який підхід до каталогу товарів обрати: unified чи per-vendor?

Порівняння підходів до каталогу товарів:

Для нішевого 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 місяців.

Вартість розробки розраховується індивідуально після аудиту вимог. Точну оцінку надамо на безкоштовному передпроектному обстеженні.

Що входить в роботу

• Проектна документація: архітектура, схеми даних, API-специфікації (OpenAPI).
• Доступи до репозиторію, CI/CD, документації з розгортання.
• Навчання команди замовника роботі з платформою.
• Технічна підтримка протягом першого місяця після запуску.

Ми гарантуємо коректність фінансових розрахунків та конфіденційність даних. Архітектурні принципи, на яких ми ґрунтуємося, підтверджені досвідом 10+ років та 50+ успішних проектів. Зв'яжіться з нами для попередньої оцінки вашого маркетплейсу — отримайте консультацію з архітектури та розрахунку виплат. Замовте аудит поточної платформи — виявимо вузькі місця та запропонуємо оптимізацію.