SDKs for TypeScript, Go, and Python

Sep 19, 2026

FrameWorks Team

Until now, a FrameWorks integration outside the browser started with a GraphQL client of your choice and a copy of the schema. The player and StreamCrafter packages covered playback and browser ingest, but creating streams, uploading files, signing viewer tokens, and checking webhook signatures from a backend meant writing that code yourself. That changes today with three packages:

@livepeer-frameworks/api on npm, for Node 22 and later and for browsers.
github.com/Livepeer-FrameWorks/sdk-go for Go.
livepeer-frameworks on PyPI, with a synchronous and an asynchronous client.

One set of operations, three languages

Each SDK generates its types from the public GraphQL schema and the same operation documents, using a standard code generator per language. When an operation changes, CI regenerates all three and fails if the committed code differs. The first release shipped 44 hand-written operations covering streams, clips, DVR, VOD uploads, playback access control, multistreaming, and developer tokens. The current 0.3 line adds a generated operation for every public root field that is not deprecated, 227 in total, so the whole public API has typed methods.

Creating a stream from a Node backend looks like this:

import { createClient, CreateStreamDocument, expectResult } from "@livepeer-frameworks/api";

const client = createClient({
  url: "https://api.example.com/graphql",
  token: process.env.FRAMEWORKS_API_TOKEN,
});
const created = await client.request(CreateStreamDocument, { input: { name: "Launch stream" } });
const stream = expectResult(created.createStream, "Stream");
console.log(stream.playbackId);

Most mutations return a union of the result and typed errors. expectResult either hands back the stream or raises an error that names what went wrong and which input field caused it, so a validation failure is something you can match on rather than a field that is quietly missing.

The same runtime in every language

Around the generated code, each SDK has a small hand-written runtime that does the same jobs: retrying transient failures with backoff, raising errors with the same names in every language, iterating over the API’s list shapes, and checking the server’s version before the first call so an operation the server does not know yet fails early instead of being sent. A mutation that may already have run is not retried behind your back.

Three helpers cover work that is not GraphQL. The upload helper sends a large file in parts with bounded concurrency and cleans up if anything fails. The playback token helper signs viewer tokens for content protected by a JWT playback policy. Webhook verification wraps the official Standard Webhooks library for each language, so the SDK carries no signature code of its own, and an event type the SDK does not know yet comes back as a raw event rather than an error. A new event type on the server never breaks an older SDK.

Two gateway changes shipped with the SDKs so they could rely on them. Errors from backend services now carry a machine-readable code, and a subscription with an expired token is closed before it starts instead of continuing as an anonymous connection. The SDKs report that as an authentication error at once.

Agreement between SDKs is tested, not assumed

Three runtimes written by hand drift apart unless something checks them. The repository has a directory of language-neutral JSON fixtures covering retries, error shapes, pagination, version checks, subscriptions, uploads, and webhooks, including the Standard Webhooks reference vector. Each SDK’s test suite loads the same files, so a change that makes one language behave differently fails CI.

For playback tokens, agreement between the SDKs was not enough. Three SDKs can agree with a fixture and all be wrong about what the edge accepts. So each SDK’s token for a shared test key is recorded, and a Go test runs all three through the same policy evaluation the media edge runs when a viewer connects. The first run of that test failed, and the fault was in the fixtures themselves: a token’s not-before time was still in the future. Every SDK had produced exactly what the fixture asked for, and the edge would have refused it.

Versions and what is not included

The SDKs stay at 0.x until the platform reaches 1.0, and all three always share a version. Each minor line names the oldest FrameWorks release it supports and supports every stable release from there on; the 0.3 line needs v0.3.11 or later. Within a line, operations are only added, and a breaking change starts a new line. On the server side, CI checks every operation of each supported line against the schema of each supported release, so a schema change that would break a field an SDK uses fails before it ships.

There are no SDKs for PHP, Ruby, Elixir, Java, or C#. Those integrations keep using the GraphQL API directly, with a Standard Webhooks library for signatures.

The SDK guide has install instructions, runnable examples in all three languages, the full list of error types, and the version table.