Skip to main content
This page covers the request pipeline - the layer between clients and the Gateway.
The payment pipeline (how the Gateway settles with Orchestrators) is covered in .
The go-livepeer binary is a routing and payment engine. It does not authenticate users, meter usage, or route premium customers to different Orchestrators.
Those concerns belong to a middleware layer sitting between clients and the Gateway process.

​
Responsibilities

The middleware handles the customer-facing interface. The Gateway handles the network interface.

​
Architecture

Three deployment patterns cover most middleware use cases.

​
Authentication

The simplest approach. Issue each customer a unique API key, validate it on every request, and store it hashed in a database.
Request: X-Api-Key: sk_live_abc123...
Middleware: hash(sk_live_abc123...) -> look up in DB -> get customer record
API keys are easy to rotate without requiring customers to re-authenticate. They are appropriate for server-to-server integrations where the key is stored securely on the client side.
For consumer-facing applications where users authenticate via OAuth (Google, GitHub, etc.), issue short-lived JWT access tokens after authentication. Validate the JWT signature on every request without a database lookup.
const jwt = require('jsonwebtoken');

function verifyToken(req, res, next) {
  const token = req.headers.authorization?.replace('Bearer ', '');
  try {
    const payload = jwt.verify(token, process.env.JWT_SECRET);
    req.customer = { id: payload.sub, tier: payload.tier };
    next();
  } catch {
    res.status(401).json({ error: 'Invalid token' });
  }
}
JWTs are appropriate for Gateways that serve end-users directly through a web or mobile application.
For Live AI (video-to-video) workloads, go-livepeer supports webhook-based RTMP authentication. The Gateway calls the webhook when an RTMP stream connects, and the webhook returns allow or deny.
-liveAIAuthWebhookUrl https://auth-service.example.com/rtmp-auth
-liveAIAuthApiKey <internal-api-key-for-webhook>
The webhook receives the stream key and can validate it against a customer database before allowing the stream through.

​
Settings

​
Middleware vs Clearinghouse

A clearinghouse combines middleware concerns with payment pipeline concerns into a single managed service: To avoid building the payment side, see for delegating ETH custody and payment accounting while keeping custom middleware for auth and routing.

Scaling

Scale middleware and Gateway instances together.

Publishing a Gateway

Make the Gateway discoverable to external developers.

Clearinghouses

Delegate payment handling to a clearinghouse service.

Orchestrator Selection

Tiering, scoring, and failover for Orchestrator selection.
Last modified on March 16, 2026