Migrate from any video API

Use this guide when FrameWorks does not have a dedicated migration page for your current platform. Most live-video APIs share the same shape: RTMP or WHIP in, HLS/WebRTC out, REST API on the side, and webhooks for events. FrameWorks also accepts Enhanced RTMP (E-RTMP) on the RTMP ingest endpoint. That makes the migration path consistent even when the source platform changes.

For common platforms such as Wowza, Mux, Bunny Stream, Cloudflare Stream, AWS IVS, Vimeo, api.video, and Ant Media, open a forum post or in-app ticket before starting a production migration. We can map the source-specific differences with you.

The seven moves

1. Account and first stream. Sign up at https://chartroom.frameworks.network or wallet-sign in. Create a stream via the dashboard or createStream(input). You get a streamKey (secret) and a playbackId (public).
2. Repoint your encoder. RTMP, RTMPS, E-RTMP, WHIP, and SRT are all supported on the ingest side. Your URL changes; the protocol doesn’t.
3. Swap the player. Use @livepeer-frameworks/player-react, -svelte, -wc, or -core depending on your stack. See Player (Playback).
4. Rewire the API integration. This is where most of the work is — see below.
5. Re-create playback access policies. Public playback IDs migrate cleanly. For JWT-gated or webhook-gated playback, see Playback Access Control — customer-managed ES256 signing keys, per-object policy, and webhook callbacks all ship today. Signing keys do not transfer between platforms; reissue on FrameWorks.
6. Re-attach multistream targets. They’re stream-scoped on most platforms, including FrameWorks.
7. Validate side by side. Don’t cut over until your dashboards agree.

What changes regardless of source

REST → GraphQL

Most live-video platforms expose a resource-oriented REST API. FrameWorks is GraphQL-first: a single /graphql endpoint with queries, mutations, and subscriptions. The schema lives at pkg/graphql/schema.graphql and you can browse it interactively at https://bridge.frameworks.network/graphql/playground.

If you’ve never written a GraphQL client, codegen is the smoothest path:

• Houdini — SvelteKit-native GraphQL codegen.
• graphql-codegen + urql / Apollo — the React standard.
• graphql-request — minimal, good for scripts.

Skipper can also draft queries for you — paste your old REST call and ask for the GraphQL equivalent.

Outbound webhooks → GraphQL subscriptions

Most platforms ship outbound HTTP webhooks for stream lifecycle, recording readiness, and multistream health. FrameWorks delivers these over GraphQL subscriptions today (WebSocket).

Generic event	FrameWorks subscription
Stream went live / idle	liveStreamEvents(streamId)
Recording / DVR lifecycle	liveDvrLifecycle(streamId)
VOD upload progress	liveVodLifecycle
Viewer connect / disconnect	liveConnectionEvents(streamId)
Track list / quality changes	liveTrackListUpdates(streamId)
Storage / artifact events	liveStorageEvents(streamId)
Transcoding / processing usage	liveProcessingEvents(streamId)

Caution

If your environment can’t hold a long-lived subscription (a serverless cron, a webhook-driven Lambda), poll the relevant query (stream(id), vodAsset(id)) on a short interval. Outbound HTTP callbacks are on the roadmap, but GraphQL subscriptions are the supported event surface today.

Bearer API key → JWT, developer token, or wallet

Three auth methods, all stateless:

• Bearer JWT — standard email/password login, refresh-token rotation.
• Developer tokens — long-lived API keys for server-side integrations.
• Wallet (EIP-191) — sign with an EVM wallet, no email required.
• x402 (EIP-3009) — gasless USDC payments per call, designed for autonomous agents.

See Agent Access for the wallet and x402 flows. Most migrations from a hosted SaaS land on developer tokens.

Playback access policies

Treat viewer-side access control separately from API authentication. FrameWorks ships:

• Public playback IDs by default — anyone with the playbackId can watch.
• JWT-signed playback — customer-managed ES256 signing keys, per-object policy, viewer JWT attached as ?jwt=<token>. Mirrors Studio’s signing-key + playbackPolicy: { type: "jwt" } model.
• Webhook-callback policies — FrameWorks POSTs an HMAC-signed body to your URL on every viewer connect; you return 200 to allow, anything else to deny. Mirrors Studio’s playback.accessControl webhook.
• DRM (Widevine / FairPlay / PlayReady) — in development.

See Playback Access Control for the full model and code samples.

Signing keys do not transfer between platforms — reissue on FrameWorks even if you have the same JWT-mint code on the source platform. The algorithm is ES256 (asymmetric); only the public key is stored on FrameWorks.

Multistream targets

Push targets are stream-scoped on FrameWorks (and on most peers). After your stream is created:

mutation Restream {
  createPushTarget(
    streamId: "stream_xxx"
    input: {
      platform: "twitch"
      name: "Twitch — main channel"
      targetUri: "rtmp://live.twitch.tv/app/live_xxxxxxxxxx_xxx"
    }
  ) {
    id
    status
  }
}

RTMP, RTMPS, and SRT push destinations are all supported.

What you gain on FrameWorks

The features that come up most often when teams move:

• 24/7 DVR archives — keep one continuous recording for long-running channels, let live viewers seek back through a bounded DVR window, and replay historical ranges through finalized chapter artifacts instead of creating a new asset every few hours.
• Retention controls — set tenant defaults and per-asset overrides for DVR, clips, and VOD so archive length matches your storage budget.
• SRT ingest — for pro encoders, firewall-traversal, and low-latency contribution.
• Pull-input streams — point FrameWorks at RTSP cameras, SRT/RIST feeds, HLS re-streams, or MPEG-TS over UDP and we open the upstream connection. Self-hosted edges can pull from RFC1918 / multicast sources via an explicit cluster opt-in — useful for IP cameras, on-prem contribution, and venue feeds. See Pull-input streams. Experimental media-engine discovery exists locally today; FrameWorks packaging through Edge, Tray, CLI, API, and dashboard workflows is tracked on the roadmap.
• LL-HLS and DASH — served from MistServer’s CMAF output alongside HLS and WebRTC.
• AV1 in the codec list.
• Sprite-sheet seek previews — generated for every recording (10×10 grid + WebVTT).
• Self-hosting and hybrid — run the whole stack on your hardware, or mix BYO edge with our managed control plane.
• Cross-cluster federation — one viewer pool routed across clusters automatically.
• Agent-first surface — MCP, wallet auth, x402 gasless USDC.
• Skipper — in-product AI consultant with diagnostics.

What’s not yet at parity

Honest list, applies regardless of source:

• AI Pipelines (text-to-image, image-to-video, ASR, live-video-to-video). Keep provider-specific AI calls on the source platform until FrameWorks exposes an equivalent surface.
• Outbound HTTP webhooks. Replaced by subscriptions for now.
• RTMP and FLV-over-HTTP pull sources. Our MistServer fork has no RTMP/FLV pull module — RTSP, SRT, RIST, HLS, DTSC, and MPEG-TS over UDP (incl. multicast) are all supported, but a pull: { source: "rtmp://…" } or https://.../*.flv upstream won’t work. If RTMP pull is on your critical path, open a ticket and we’ll prioritize it.
• C2PA / creator-ID provenance signing on transcode. Not exposed as a public FrameWorks API today.
• First-class Python and Go SDKs. Use GraphQL codegen against the public schema until first-party SDKs are published.
• DRM (Widevine / FairPlay / PlayReady). In development.
• Multi-participant SFU rooms. These are not exposed as a FrameWorks product surface today.
• Per-target rendition selection on multistream.
• VOD library import tooling. Concierge-only today — reach out.

Beta flags worth knowing

• Billing rates are still maturing. Rates may adjust; allowances at signup are honored.
• Self-hosted and hybrid production cutovers need operator validation. Test DNS, TLS, firewall policy, capacity, node enrollment, and upgrade runbooks before moving production traffic.
• Marketplace primitives ship; the vetted public marketplace program is on the roadmap. Validate operator vetting, pricing, approval flow, and support boundaries before relying on third-party clusters for production traffic.
• Mobile apps — native iOS and Android clients are in development; not yet generally available.

Get help

If your source platform is not covered by a dedicated guide, include the platform name, current API features in use, and migration deadline when you contact us. That gives support enough context to point you at the closest existing path or scope a platform-specific guide.

Channel	Best for	Where
Skipper (AI consultant)	Quick troubleshooting, API discovery, diagnostics, after-hours, non-human callers	Dashboard /skipper · ⌘J in docs · MCP at /mcp
In-app ticketing	Account-specific issues, billing, anything tied to your tenant data, library-migration help	Dashboard /support
Forum	Long-form Q&A, recipes, searchable community knowledge	forum.frameworks.network
Discord	Real-time chat, casual questions	Join
GitHub	Bugs, feature requests, deeper technical threads	Livepeer-FrameWorks/monorepo