Build with the DynTube API

Base URL

All requests go to the versioned base URL over HTTPS. The current public version is v2; check the API reference before pinning a client to any path on this page, because the reference is the authoritative contract and this hub is an orientation.

https://api.dyntube.com/v2

Authentication

Authenticate with an API key sent as a bearer token in the Authorization header. Keys are issued per account and carry the permissions of that account, so treat one as you would a password: keep it server-side, never ship it in browser code, and rotate it if it is ever exposed.

Authorization: Bearer $DYNTUBE_KEY

Quick start

1. Create an API key in your account settings and store it as an environment variable.
2. Call the project list endpoint to confirm the key works and to find the project you want to upload into.
3. Upload a video, either from a URL your server can reach or as a file.
4. Poll the video until its status is ready, or subscribe to a webhook so you are told instead of asking.
5. Read the video to get the key you need for the embed.

Example request

curl https://api.dyntube.com/v2/projects \
  -H "Authorization: Bearer $DYNTUBE_KEY"

Errors

Choose the right API surface

Use v2 for new management integrations. Existing v1 integrations continue through the compatibility gateway, and every v1 reference page displays a compatibility notice so teams can identify the contract they are maintaining.

• Start new management integrations with the generated v2 OpenAPI document and its published resource paths.
• Use the marked v1 compatibility pages when maintaining an integration already built on that surface.
• Follow a documented v1-to-v2 mapping only when the current reference publishes that exact replacement.
• Ask support to confirm the recommended path when an established v1 workflow is important to your roadmap.

API reference

The reference is grouped by resource. The groups below are an orientation, not a contract: for the exact resource paths, parameters, response shapes and errors, read the reference itself.

• Videos and uploads — getting source media in, and reading what came out.
• Projects — the container that holds your settings.
• Live streaming and schedules — creating streams and reading what they produced.
• Analytics and reports — engagement, aggregated.
• Subscribers, subscription plans and access grants — who may watch what.
• API keys, app clients and viewer tokens — how a request proves who it is.

Controlling the player from your front end

The player exposes events and methods so your interface can react to playback rather than sit beside it — marking a lesson complete, gating a next button, or recording progress against your own user record. The player documentation carries the current method and event names; treat that, not this paragraph, as the contract.

Looking for user documentation?

If you are configuring the platform rather than integrating with it, start in the help centre, which documents the dashboard. The two surfaces are documented separately because they are not guaranteed to expose the same operations.