Developers
A REST API for video your application owns
Upload, organise, protect and grant access to video from your own code, so the library behaves like part of your product rather than a place your team logs into separately. Token-authenticated HTTP, webhooks for state changes, and no proprietary client required.
curl https://api.dyntube.com/v2/videos \
-H "Authorization: Bearer $DYNTUBE_API_KEY"The problem
What a dashboard-only video platform costs an engineering team
If video can only be managed by a human in a web interface, any feature that touches video becomes a manual process. Someone uploads, someone copies an embed code, someone pastes it into a CMS field, and someone remembers to revoke access when a subscription lapses.
The consequence is that video never quite belongs to your application. Your onboarding flow cannot create a lesson, your billing webhook cannot grant access, your admin tool cannot show a customer their own library, and every one of those gaps is filled by a person following a checklist.
An API closes the gaps. Uploads originate from your own forms, projects mirror your own tenancy, and access follows your own subscription state — because the thing that knows whether someone should be watching is your system, not a video dashboard.
The surface
What the current public contract exposes
Capability groups from the current public contract. The API reference has the exact endpoints, parameters and payloads — this page names what exists rather than restating a specification that would drift.
- Videos and upload sessionsLibrary
- Create, read, update and remove video records, and open upload sessions for getting media in. Upload sessions are what make browser-side uploads possible without handing a key to the browser.
- ProjectsOrganisation
- Project operations, so your own tenancy — customers, courses, clients — can be mirrored in the structure that also carries protection settings.
- Live streamsLive
- Live-stream operations, so creating an event and retrieving its ingest details can happen from your own scheduling flow rather than by hand before each broadcast.
- Subscribers, plans, subscriptions and access grantsAccess
- Subscriber, subscription-plan, subscription and access-grant resources. This is the group that lets your billing system drive who can watch what, and revoke it when that changes.
- AnalyticsReporting
- Pull plays, watch seconds and completion into your own dashboards. Aggregate reporting is there by default; on Plus and larger plans, when your embed supplies its own user identifier, the API returns that customer-supplied value with accepted playback events so per-user reporting becomes possible.
- WebhooksEvents
- Event notifications to an endpoint you configure, so your application reacts when a video finishes processing instead of polling for it. Deliveries are inspectable and retryable, which is what makes a webhook integration debuggable rather than mysterious.
- The contract itselfv2, generated
- The v2 management surface is published as a generated OpenAPI 3.1 document, so the description of the API and the API are the same artefact. Point a client generator at it and your client is current by construction. The written v1 guides remain available separately for integrations already built on them.
Choosing an integration shape
Three ways to get video in
Retained in full from the legacy source, which described these accurately. Which one you want is decided by where the file already is.
- 01
Upload from a URL, server-side
- 02
Upload a file, server-side
- 03
Upload from the browser, via a signed session
- 04
React to the result with a webhook
What people build
The integrations this surface is for
Each of these is a case where the dashboard alone would leave a manual step in the middle.
Access driven by your billing
Your payment webhook creates a subscriber, attaches a subscription and grants access; a cancellation revokes it. The video platform follows your source of truth instead of holding a second one.
Multi-tenant products
A project per customer, created when they sign up, so each tenant’s library and protection settings are isolated by construction rather than by convention.
User-generated uploads
Signed upload sessions let your users upload from your own interface without your key or your bandwidth being involved.
Reporting in your own tools
Pull plays, watch seconds and completion on a schedule, including customer-supplied user identifiers when enabled, and keep them beside your other product metrics.
Questions
Developer questions
Two of these correct answers this page previously gave.
What is the base URL and current version?
The current management contract is v2, and the authoritative description of it is the generated OpenAPI 3.1 document at /dev/api-v2/openapi.json — import that into your client generator or HTTP client and you are working from the contract itself rather than from prose. The written v1 endpoint guides stay published under /dev for integrations already built against them, and they carry their own v1 notice. Take the base URL from the generated document.
How do I authenticate?
Token authentication: a management API key sent as a bearer token on each request, issued and rotatable from the dashboard. Management credentials belong on your server and nowhere else — the signed browser upload path exists precisely so a key never has to reach a client, and a key that has only ever lived server-side is one you can rotate without breaking a page.
Which languages and SDKs are supported?
It is an HTTP API with JSON payloads, so anything that can make an authenticated HTTP request can call it. We have removed the previous list of officially supported languages and SDKs from this page rather than imply a level of maintained client support we have not evidenced — check the reference for what is actually published.
Can users upload from the browser without exposing my key?
Yes, and this is the pattern to use for any user-facing upload. Your server opens a time-limited upload session; the browser uploads to that session. Your key stays server-side and the session expires on its own.
How do I know when a video is ready?
Configure a webhook endpoint and handle the event when processing completes. Transcoding time depends on the source, so an event-driven update is the only reliable design — do not build a UI that assumes a fixed delay.
Are videos uploaded via the API protected?
They inherit the protection mode of the project they are created in. This is a correction: the previous answer promised AES-128 encryption for anything uploaded programmatically, but protection is a project-level setting and DRM and AES are mutually exclusive per project. Set the project up correctly and the API follows it.
Is API access included, and are there per-call charges?
API availability and limits are plan-dependent, and this page no longer asserts otherwise. It previously claimed blanket inclusion and the absence of usage charges; neither was backed by current catalogue data. Ask us to confirm your entitlement in writing before building on it.
Start from the reference, not from this page
Get a key, make one authenticated request against the current contract, and wire a webhook. That is the whole shape of the integration, and it takes an afternoon.