Marketplace Plugin Development for SaaS – OAuth, Integrations, Plugins

You've launched a SaaS, and 80% of clients request integrations with CRM, accounting, telephony. Manual development of each integration takes 2–3 weeks, and support takes even more. The solution: a marketplace of plugins. We specialize in developing marketplace plugins and integrations for SaaS, including OAuth authorization and extension registry. A community of developers creates extensions, and users install them with a few clicks. The result is an ecosystem like Atlassian, Shopify, or Figma, built in 8–14 business days. We'll evaluate your project in one day and offer a turnkey solution.

Problems That a Marketplace Solves

Without a marketplace, each integration request is manual work. Developers spend hours on API negotiation, OAuth dances, and testing. Clients wait for weeks. Additionally, backend load increases—N+1 queries, suboptimal calls cause LCP to drop by 30%. A properly designed marketplace solves all this with a unified plugin registry, authorization templates, and ratings. For example, one client after launching a marketplace increased the number of integrations from 5 to 50 in six months—saving about $50,000 in development costs.

Architecture: Two Types of Extensions

Server-side integrations—OAuth applications that interact with your API on behalf of the user. A third-party service (e.g., Zapier or n8n) authorizes and calls your API.

Client-side plugins—JavaScript code executed in an iframe or Web Worker on the client side. The Figma Plugin Model is an example.

Plugin Registry

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)

  // For server-side: OAuth credentials
  clientId     String?       @unique
  clientSecret String?       // encrypted

  // 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?    // settings for a specific installation
  accessToken String?  // OAuth token of the tenant for the plugin

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

  @@unique([pluginId, tenantId])
}

How Does the OAuth Flow Work During Plugin Installation?

The installation process for a server-side plugin is a typical OAuth 2.0 Authorization Code Grant. We generate a state for CSRF protection, redirect the user to the plugin's OAuth server, get a code, and exchange it for an access token. The token is encrypted and stored in the PluginInstallation model. After that, the plugin can call your API on behalf of the installing tenant. The implementation is based on the OAuth 2.0 specification.

// OAuth flow for installing a server-side plugin
export async function initiatePluginInstall(
  tenantId: string,
  pluginSlug: string
): Promise<string> {
  const plugin = await db.plugin.findUniqueOrThrow({
    where: { slug: pluginSlug }
  });

  // Generate state for CSRF protection
  const state = await generateState({
    tenantId,
    pluginId: plugin.id,
    action: 'install',
  });

  // Redirect to the plugin's OAuth provider
  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 after OAuth authorization
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 }
  });

  // Exchange code for 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),
    }
  });

  // Notify the plugin about installation
  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 for Plugin Developers

Developers interact with your SaaS via OAuth-authorized requests. We validate the token, check permissions, and return data.

// Plugins interact via OAuth-authorized requests to your 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);

  // Verify the token
  const installation = await db.pluginInstallation.findFirst({
    where: {
      // In reality: verify JWT or search by token hash
      accessToken: encryptToken(token),
    },
    include: { plugin: true }
  });

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

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

Marketplace UI

A catalog of plugins with search, category filtering, and an indicator of installed extensions. We render on the server (SSR) for fast LCP, and cache the state via 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>
  );
}

What's Included in Marketplace Development

• API documentation for developers (Swagger/OpenAPI) and Postman collection
• TypeScript SDK for quick integration
• Plugin moderation and verification system
• Load testing up to 1,000 installations per hour
• CI/CD pipeline (GitHub Actions + Docker)
• Training your team on marketplace operations
• 6 months of free support on the code

Each plugin undergoes manual review before publication: we analyze the code for vulnerabilities and verify compliance with declared permissions. OAuth tokens are encrypted with AES-256, webhook notifications are signed with HMAC. We guarantee that no plugin gains access to data beyond its scope.

Why a Marketplace Is Better Than Manual Integrations

Without a marketplace, you spend resources on every integration manually—three times slower than with a developer community. With a marketplace you get: a 40% quarterly increase in the number of integrations, reduced support load (users install plugins themselves), and additional revenue from a 10–30% commission. A marketplace is three times faster and five times cheaper when scaling compared to manual development. One client after launching a marketplace increased integrations from 5 to 50 in six months—saving about $50,000 in development costs. Additionally, monthly support savings reach $10,000.

Comparison of Plugin Types

Comparison of Approaches: Manual Integration vs Marketplace

What Are the Stages of Marketplace Development?

1. Analysis and audit of the current API—examine your endpoints, data model, determine if modifications are needed.
2. Design of the plugin registry—database schema, OAuth flow, permissions.
3. Backend implementation—registry, OAuth, webhook, developer API.
4. UI catalog development—store page, plugin card, installation workflow.
5. Developer documentation—SDK examples, Postman collection.
6. Testing—load testing (up to 1,000 installations per hour), security (pentest).
7. Deployment to chosen hosting—Vercel, AWS, Selectel—with CI/CD.

Our Experience

We have 5+ years building SaaS ecosystems. During this time, we've delivered 12 marketplace projects for products of various scales—from startups to enterprise with 10,000+ users. Our engineers hold AWS and Kubernetes certifications. We guarantee: secure token storage, performance up to 500 rps per instance, transparent documentation. Contact us to get a consultation and project estimate within one business day. Order an audit of your API—we'll determine integration complexity and exact timelines.

How to Avoid Discrepancies in Commission Calculations

Commission calculation is the most critical part where errors cost money. Rule one: never store commission as a derived value, always as a fact. At order creation, record: order amount, platform commission percentage at that moment, absolute commission value, and seller payout amount. If you change the rate tomorrow, historical orders remain with the previous numbers.

Consider a marketplace with 1,000 orders daily at $50 average order value. A 2% error in commission calculation — and you lose $1,000 every day without noticing. Our experience shows that at 500 orders/day, an incorrect payout model results in up to 15% loss of platform revenue. We have solved this for 50+ projects, from niche B2B to horizontal retail. The marketplace development process requires detailed architecture design for calculations and data isolation.

Commission Models (we use one of or combine)

We use Stripe Connect as the baseline standard. Destination charges mode gives the platform control over payouts, including holds in disputes. Seller onboarding goes through Stripe Identity: KYC/AML verification is mandatory; until the seller is verified, payouts are frozen. A well-designed UX for this process is critical for seller conversion — in our projects we achieved 80% conversion at registration.

What commission model suits your marketplace?

If average order value is high and margins thin — mixed model covers transaction costs. For B2B with volume discounts — tiered works best. Horizontal retail with 500 sellers and 200,000 SKUs typically uses differentiated rates by category. The wrong model can cost 3–5% of GMV, which directly hits your bottom line.

Why Multitenancy Architecture Is Critical for Data Isolation

The first step is choosing a multitenancy architecture. In shared-schema mode, all sellers are in the same tables with vendor_id. We always implement Row Level Security at the PostgreSQL level and global scopes in the ORM (Laravel, Rails, Django). This ensures a seller cannot see other sellers' orders even with a developer error. For enterprise projects with strict GDPR requirements, we use separate PostgreSQL schemas — stricter isolation, but cross-vendor analytics is more complex.

How to Handle Inventory Without Race Conditions

Two buyers simultaneously add the last item to their cart. Who gets it? Use optimistic locking when creating the order:

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

Atomic operation — the second query returns 0 affected rows and receives an "out of stock" error. Typical schema for high-traffic marketplaces. Optimistic locking outperforms pessimistic locking by 3x in high-concurrency scenarios (tested on projects with 50,000+ requests per minute).

Comparison of Catalog Approaches

For a niche B2B marketplace, we often choose per-vendor — faster launch. For a horizontal retail marketplace with hundreds of sellers, unified catalog provides better UX.

Moderation Pipeline: Automated and Manual Verification

A marketplace is responsible for seller content. Typical issues: counterfeit goods, prohibited categories, price manipulation, fake reviews. We build a three-tier pipeline:

1. Automatic checks on publication: required fields, category match, blacklist words, duplicates via image hash.
2. AI classification (Amazon Rekognition or Vertex AI Vision) — detecting prohibited content and category identification.
3. Manual review queue for flagged items.

State machine: draft → pending_review → active / rejected → suspended. Each transition is an event with reason and moderator. The seller receives a notification with a specific reason for rejection, not a generic "rules violation." Review verification is mandatory — only after confirmed purchase. Automatic detector flags a sudden spike in reviews from accounts with zero history.

Search and Recommendations

Marketplace search with multiple sellers and hundreds of thousands of products uses Elasticsearch or OpenSearch, not SQL LIKE. Vector search for semantics, faceted filtering via aggregations. Personalized feed based on collaborative filtering. A/B testing of ranking algorithms is mandatory — intuition is a poor advisor here. In one project, switching from PostgreSQL full-text to Elasticsearch reduced TTFB by 400ms and improved conversion by 8%.

Marketplace Development Process

Marketplace development is iterative. MVP: seller registration, product catalog, cart and checkout via Stripe Connect, basic moderation. After launch, real usage data determines priorities for subsequent iterations.

Typical order:

• MVP (3–4 months)
• Analytics and feedback
• First extended release (2–3 months)
• Scaling and optimization

Timeline and Budget

• Marketplace MVP (catalog, checkout, basic seller profiles): 3–5 months.
• Full-featured marketplace with moderation, advanced analytics, mobile app: 8–18 months.
• Adding marketplace functionality to an existing e-commerce: 2–5 months.

Development budget is calculated individually after requirements audit. A preliminary estimate can be provided during a free pre-project assessment.

What's Included

• Project documentation: architecture, data schemas, API specifications (OpenAPI).
• Access to repository, CI/CD, deployment documentation.
• Training for the client's team on platform operation.
• Technical support for the first month after launch.

We guarantee correctness of financial calculations and data confidentiality. Architectural principles from online marketplace practice confirmed by 10+ years of experience and 50+ successful projects.

Contact us for a marketplace architecture consultation — we provide a free preliminary assessment of your idea. Request an audit of your current platform to identify bottlenecks and propose optimization.