Why use a private service for backend APIs in a marketplace?

A private service has no public onrender.com URL. Your public gateway authenticates customers and proxies requests over Render's private network. Backend APIs are not directly reachable from the internet.

Should billing jobs run on a web service or a background worker?

Run recurring billing aggregation on a background worker or cron job. Workers and cron jobs can initiate outbound requests but do not receive inbound HTTP traffic, which fits batch invoice generation.

How do I pass a Postgres connection string in render.yaml?

Reference the database with fromDatabase and property: connectionString. See Blueprint environment variables.

Can I use Render Key Value instead of self-hosted Redis for rate limiting?

Yes. Render Key Value is Redis-compatible. Connect from your gateway using the instance internal URL on the private network.

What happens when a customer exceeds their rate limit?

Return HTTP 429 from the gateway with X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers. Do not proxy the request to backend APIs when the limit is exceeded.

Do failed backend requests count toward billing?

That is your product decision. The example invoice query excludes response_status >= 500. Many marketplaces bill only on successful (2xx/3xx) or billable (4xx excluded) responses. Document the rule in your plan terms.

How do I expose marketplace documentation?

Serve aggregated OpenAPI specs from the gateway or a separate docs web service. Refresh specs when backend services deploy, either by polling /.well-known/openapi.json or triggering updates from a deploy hook.

Platform

How to build and deploy an API marketplace

July 15, 2026

An API marketplace is a platform that offers multiple APIs through a unified interface, providing centralized authentication, billing, and documentation. The core technical challenge involves routing customer requests to different backend services while tracking usage per customer and enforcing plan-specific rate limits.

The key components include an API gateway for request routing, authentication middleware to identify customers, rate limiting logic that respects subscription tiers, usage tracking for billing, and hooks into payment processors.

Required software:

Node.js 18+ or Python 3.10+
PostgreSQL 14+ for customer data and usage metrics (MongoDB works if you prefer it locally)
Redis 7+ or Render Key Value for rate limiting and caching
Basic knowledge of REST APIs and middleware patterns

Environment configuration: Set environment variables for service discovery: WEATHER_API_URL, PAYMENTS_API_URL, database connections, and JWT secrets. In production on Render, manage these through environment variables.

An API marketplace implements a layered architecture where the request flow follows: incoming request → API gateway → authentication verification → rate limit check → service router → backend API → response transformation → usage logging.

The gateway handles authentication middleware that extracts API keys, rate limiting middleware that queries Redis, and routing that proxies requests to backend services.

Marketplace metadata includes customer records (ID, plan tier, billing status), API subscriptions, rate limit configurations per plan, and usage logs for billing.

plaintext

Client Request (with API key)
    ↓
[API Gateway]  // Gateway: auth, routing, usage tracking
    ↓
[Auth Middleware] → Validate key → Fetch customer + plan
    ↓
[Rate Limiter] → Check Redis → Allow/Deny
    ↓
[Service Router] → Match path → Proxy request
    ↓
[Backend APIs]  // Your actual API services
    ↓
[Response Logger] → Record usage → Return response

The gateway serves as the single entry point, implementing path-based routing (/weather/* routes to weather service, /payments/* routes to payment service). The gateway extracts customer context by reading the X-API-Key header, queries the database for the customer record, and caches this lookup in Redis.

Usage logging occurs after receiving the backend response, capturing: customer ID, service identifier, timestamp, HTTP method, response status, and response time.

This simplified example demonstrates the basic gateway pattern:

javascript

const express = require('express');
const app = express();

app.use(async (req, res, next) => {
  const apiKey = req.headers['x-api-key'];
  const customer = await getCustomerByKey(apiKey);
  req.customer = customer;
  next();
});

app.use('/weather/*', async (req, res) => {
  await logUsage(req.customer.id, 'weather', req.path);
  proxyToService(WEATHER_API_URL, req, res);
});

Adapt this pattern for your use case by adding error handling, timeout logic, and retry mechanisms.

Generate cryptographically secure API keys (32+ bytes, base64-encoded). Do not store bcrypt hashes for API key lookup: bcrypt uses a unique salt per row, so you cannot query by bcrypt(presented_key). Store a deterministic hash such as SHA-256 (optionally scoped with a key-id prefix), look up by that hash, then verify with a constant-time compare. Keep bcrypt for password hashing only. The customer table includes id, api_key_hash, plan_id, status, and created_at.

This example illustrates the authentication middleware pattern:

javascript

const crypto = require('crypto');

function hashApiKey(apiKey) {
  return crypto.createHash('sha256').update(apiKey).digest('hex');
}

function hashesMatch(storedHash, candidateHash) {
  const a = Buffer.from(storedHash, 'hex');
  const b = Buffer.from(candidateHash, 'hex');
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}

async function getCustomerByKey(apiKey) {
  const keyHash = hashApiKey(apiKey);
  const customer = await db.query(
    'SELECT * FROM customers WHERE api_key_hash = $1',
    [keyHash]
  );
  if (!customer || !hashesMatch(customer.api_key_hash, keyHash)) {
    return null;
  }
  return customer;
}

async function authenticateRequest(req, res, next) {
  const apiKey = req.headers['x-api-key'];
  
  if (!apiKey) {
    return res.status(401).json({ 
      error: 'API key required',
      message: 'Include X-API-Key header'
    });
  }

  const customer = await getCustomerFromCache(apiKey) 
    || await getCustomerByKey(apiKey);
  
  if (!customer || customer.status !== 'active') {
    return res.status(403).json({ error: 'Invalid or inactive API key' });
  }

  req.customer = customer;
  req.plan = await getPlanDetails(customer.plan_id);
  next();
}

After authentication, check if the customer's plan includes access to the requested service using a service_subscriptions table.

Use Redis keys with atomic counters (INCR) and keys like ratelimit:{customer_id}:{service}:{window}. Different subscription tiers have different quotas enforced per customer per service.

This minimal example demonstrates the rate limiting concept:

javascript

async function checkRateLimit(customerId, service, plan) {
  const window = Math.floor(Date.now() / 3600000); // Hourly
  const key = `ratelimit:${customerId}:${service}:${window}`;
  
  const current = await redis.incr(key);
  
  if (current === 1) {
    await redis.expire(key, 7200);
  }
  
  const limit = plan.limits[service] || plan.default_limit;
  
  if (current > limit) {
    const resetTime = (window + 1) * 3600000;
    throw new RateLimitError(limit, resetTime);
  }
  
  return { allowed: true, remaining: limit - current };
}

When rate limits are exceeded, return HTTP 429 with headers X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset.

Each usage event includes: event_id, customer_id, service_name, endpoint_path, timestamp, response_status, and response_time_ms. Store events in a time-series table partitioned by month.

Connect usage data to billing providers through scheduled jobs that aggregate requests per customer per service and create invoice line items:

javascript

async function generateInvoices(billingPeriodEnd) {
  const customers = await getActiveCustomers();
  
  for (const customer of customers) {
    const usage = await db.query(`
      SELECT service_name, COUNT(*) as requests
      FROM usage_events
      WHERE customer_id = $1
        AND timestamp >= $2 AND timestamp < $3
        AND response_status < 500
      GROUP BY service_name
    `, [customer.id, customer.billing_period_start, billingPeriodEnd]);
    
    const charges = calculateCharges(usage, customer.plan);
    
    await stripe.invoiceItems.create({
      customer: customer.stripe_id,
      amount: charges.total,
      currency: 'usd',
      description: `API usage: ${billingPeriodEnd}`
    });
  }
}

Adapt this pattern to include error handling, retry logic, and notifications for failed billing attempts.

Build a documentation service that fetches OpenAPI specs from backend services at /.well-known/openapi.json, enriches them with marketplace-specific information, and serves them through Swagger UI. Cache specs in Redis and refresh via webhooks when services deploy updates.

Deploy using multiple service types: a web service for the public API gateway, private services for backend APIs, a background worker for billing jobs, and Render Postgres:

yaml

services:
  - type: web
    name: api-gateway
    runtime: node
    buildCommand: npm install
    startCommand: node gateway.js
    healthCheckPath: /health
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: marketplace-db
          property: connectionString
      - key: REDIS_URL
        fromService:
          name: marketplace-cache
          type: keyvalue
          property: connectionString
      - key: WEATHER_API_URL
        fromService:
          name: weather-api
          type: pserv
          property: hostport

  - type: pserv
    name: weather-api
    runtime: node
    buildCommand: npm install
    startCommand: node weather.js

  - type: worker
    name: billing-worker
    runtime: node
    buildCommand: npm install
    startCommand: node workers/billing.js
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: marketplace-db
          property: connectionString

  - type: keyvalue
    name: marketplace-cache
    maxmemoryPolicy: allkeys-lru
    
databases:
  - name: marketplace-db
    databaseName: marketplace
    plan: basic-1gb

Use Render's private network so backend APIs deployed as private services are reachable only from other services in the same workspace and region. The gateway stays public on its onrender.com URL while backend APIs have no public endpoint.

For rate limiting and caching, add a Render Key Value instance and reference its internal connection URL from the gateway.

Focus on integration tests covering authentication (valid/invalid keys, suspended accounts), rate limiting (within/exceeding quotas, different plans), and usage tracking (successful requests logged, failed requests excluded).

For production, add security enhancements like request signing and IP allowlisting, implement distributed tracing, and build a developer portal for customer self-service. The architectural patterns demonstrated here scale from prototype to production by enhancing each component independently.

How to build and deploy an API marketplace

Prerequisites and environment setup

Architecture overview

The API gateway pattern

Authentication and customer context

Rate limiting with customer context

Usage tracking and billing integration

Documentation as infrastructure

Deploy on Render

Testing and production considerations

Frequently asked questions