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.
POST /v2/access-grants
Authorization: Bearer $DYNTUBE_API_KEYThe 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
- 01
Mirror your tenancy with projects
- 02
Take uploads from your own interface
- 03
Embed the player in your app
- 04
Keep identity and billing in your app
- 05
Drive access from your own subscription events
- 06
React to processing with webhooks
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.