Skip to main content
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.
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.
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.
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 May 31, 2026