SaaS

Video as part of your product, not beside it

If your application has onboarding, lessons, recordings or customer-uploaded media, the video layer has to be drivable from your own code. Uploads from your forms, projects that mirror your tenancy, and access that follows your own subscription state.

Grant access when a subscription starts
POST /v2/access-grants
Authorization: Bearer $DYNTUBE_API_KEY

The problem

Where video usually breaks a product roadmap

Video arrives in a SaaS product as a feature request that sounds small: let customers upload a recording, or add a lesson to a course module. Then it turns out somebody has to store large files, transcode them into something that plays on a phone, and decide who is allowed to watch — none of which is your product.

The usual shortcut is a public platform embed, and it fails the moment the content is private. Unlisted links are not access control, and a per-customer library on somebody else’s platform is not something you can operate.

The alternative is a video layer you drive from your own backend, where your application stays the source of truth about who your users are and what they have paid for.

The workflow

The integration, in the order you would build it

  1. 01

    Mirror your tenancy with projects

    Create a project per customer or workspace so each tenant’s media and settings are separated by construction rather than by convention. Projects also carry protection and player configuration.

  2. 02

    Take uploads from your own interface

    For user-facing uploads, open a signed upload session on your server and let the browser upload directly to it — your API key never reaches the client. For imports and pipelines, upload from a URL or from your server.

  3. 03

    Embed the player in your app

    The player embeds in your own UI. Test it against your framework and your content-security policy: a strict CSP or a sandboxed iframe is what decides embed compatibility, not the framework you happen to use.

  4. 04

    Keep identity and billing in your app

    Your product authenticates the user and knows their plan. That does not move. What you do is tell the platform the result — which brings us to the next step.

  5. 05

    Drive access from your own subscription events

    When a payment succeeds, your backend creates or grants access; when it lapses, it revokes. One call each way, from the system that already knows. That is the entire seam between the two.

  6. 06

    React to processing with webhooks

    Transcoding is asynchronous, so update your own record when the event arrives rather than polling or showing a spinner with a guessed duration.

The mechanisms

What the current contract gives you

Capability groups from the current public contract. Exact endpoints, parameters and authentication live in the API reference, which is the thing to build against.

Videos and upload sessions/v2
Video records plus upload sessions, including the signed-session path that makes browser uploads safe.
Projects/v2
The structure you map your tenancy onto, carrying protection and player settings per tenant.
Subscribers, plans, subscriptions, access grants/v2
The access resources your billing events drive. This is what lets entitlement follow your own subscription state instead of being maintained twice.
Live streams/v2
Live-stream operations, if your product schedules or hosts events.
Aggregate analytics/v2
Aggregate plays, watch seconds and completion, pullable on a schedule into your own dashboards.
Customer-identified analyticsPlus and larger plans
When your embed supplies a stable user ID from your own system, accepted playback events can be connected to that identifier for per-user viewing analysis.
WebhooksEvents
Event delivery to an endpoint you configure, so your application reacts to state changes.

Fit

The integrations this shape suits

  • Best for — multi-tenant media

    Each customer gets a project; their media and settings stay separated without you operating separate accounts.

  • Best for — user-generated uploads

    Signed upload sessions let users upload from your UI without your key or your bandwidth in the path.

  • Best for — entitlement-driven access

    Your billing webhook grants and revokes. Entitlement lives in one place — yours — and the video layer follows it.

  • API-driven product experiences

    Use the /v2 API and signed upload or playback workflows when video needs to behave like a native part of your product. Keep identity, checkout and billing in your application, then confirm the plan entitlement and volume you need in writing.

Build the seam first

Create a project, open a signed upload session, embed the player in your own app and grant access from a test billing event. If that works, the rest of the integration is detail.