For developers

A video API you can build on without wrapping it in defences

Any video platform can offer endpoints. What decides whether it survives in your codebase is duller: does a retried create charge you twice, can you tell whether an encode finished without polling a list endpoint, do errors arrive as a shape you can switch on, and is there a machine-readable contract you can generate a client from. This page answers those, from the document the site actually serves.

See the API referenceQuick start
List videos
curl https://api.dyntube.com/v2/videos?limit=50 \
  -H "Authorization: Bearer $DYNTUBE_API_KEY"

  • Generated contract

    OpenAPI 3.1 at a stable URL, built from the registry.

  • Safe retries

    Creates require an idempotency key and replay the original response.

  • Async by design

    Long work returns an operation you poll or cancel.

The problem

The integration cost is not the first request

The first call against any video API takes twenty minutes. The cost arrives three months later, in the code you wrote around it: the deduplication table because a timed-out create sometimes made two videos, the polling loop because nothing told you when an encode finished, the string matching on error messages because errors came back as prose, the hand-maintained client because there was no contract to generate one from.

None of that is video work. It is compensation for properties the platform did not provide, and it is permanent — it has to be maintained, understood by whoever joins next, and re-verified every time the vendor changes something quietly.

So the useful question for an evaluation is not "does it have an upload endpoint". It is which of those compensating layers you will not have to write. The sections below answer that one at a time.

The contract

Six properties, each removing a layer you would otherwise write

All six are visible in the generated OpenAPI document linked from the API reference, so you can check every one of them before writing a line of integration code.

A generated, machine-readable contractOpenAPI 3.1
The specification is generated from the API contract registry rather than written alongside it, so it describes exactly the operations that projection defines and nothing beyond them. Point a client generator, an HTTP client or an editor at the URL. It is a specification file rather than a browsable console — we would rather ship the thing your tooling consumes than a demo page.
Idempotency keys required on createsHeader, mandatory
Create operations require an Idempotency-Key header, and a duplicate request replays the original response instead of creating a second record. This is the property that removes an entire class of defensive code, and it is required rather than optional, so it cannot be skipped under deadline pressure. A conflicting key returns a distinct error code rather than failing ambiguously.
Asynchronous work is an object, not a guessOperations resource
Long-running work returns an operation you can list, fetch by id and cancel. Where you would otherwise re-list a collection on a timer and diff it, there is a record to read instead — and something to show a user while they wait rather than a spinner with no state behind it.
Errors are typed, not proseEvery endpoint
Failures return a consistent envelope whose code comes from a fixed enum — among them authentication required, invalid key, insufficient scope, permission denied, feature not available, limit exceeded, validation error, conflict, idempotency key conflict, operation in progress, rate limited and provider unavailable. You branch on a value, not on a substring of an English sentence that may be reworded.
Cursor pagination and explicit sortingList endpoints
Lists take a cursor and a limit, with declared sort fields and filters, rather than an offset that quietly skips records when the collection changes underneath you. Videos, for instance, filter by status, project and search, and sort on created, updated or title.
Bulk mutations that report per itemBatch endpoints
Batch operations accept up to a hundred items and return per-item successes and failures rather than a single pass-or-fail. A migration where three of four hundred titles fail validation is a normal Tuesday, and it should not be an all-or-nothing transaction.

The surface

What you can actually drive

Grouped by the resource families in the served contract. This is what exists rather than what is planned.

  • Videos

    Create, read, update, archive, restore and delete, plus status, captions, transcripts, thumbnails and embed details. Batch lifecycle mutations up to a hundred at a time.

  • Upload sessions

    Create an upload session rather than posting bytes through your own server, so a browser or a device can transfer directly without your API key travelling with it.

  • Live streams

    The largest family in the contract: streams, ingest details and ingest-key rotation, playback, scheduling, archiving and private links.

  • Audio and transcripts

    Audio assets alongside video, with transcription and translation requests, transcript and caption reads, reprocessing and AI retry.

  • Access and viewer tokens

    Access grants as first-class records, minted viewer tokens for a subscriber, and per-asset private links that can be revealed, rotated and revoked.

  • Members and access

    Manage member records, access grants and viewer tokens so your own identity or commerce system can decide which authenticated viewers may play protected media.

  • Projects and channels

    Organise assets by project and automate searchable channel libraries your application embeds, while keeping billing and checkout in your existing commerce system.

  • Analytics

    Separate aggregates for audience, content, engagement, videos, live streams, bandwidth, storage, interactions and playback quality of experience.

  • Webhooks and keys

    Webhook endpoints with rotatable signing secrets, an inspectable delivery log with manual retry, and API keys you can create, rotate and revoke.

Operating it

Credentials and event delivery, with the sharp edges named

The two parts of an integration that cause incidents later rather than errors now.

Bearer API keys, scoped per routeAuthorization header
Authentication is a management API key sent as a bearer token, and scopes are enforced per route — so a key that reads analytics is not automatically a key that deletes videos. Management keys stay server-side, which is what keeps rotation a backend deployment rather than a front-end release. Keys are themselves API objects: create, list and revoke them from code rather than from a settings screen.
Rotation without a window of downtimeRotate operation
A key can be rotated, which invalidates the previous secret and returns a new one exactly once. Rotating an already-revoked key returns a conflict rather than quietly succeeding, so an automated rotation job can tell the difference between "done" and "already gone".
Secrets are returned onceKeys and webhook endpoints
A new API key secret and a new webhook signing secret are each returned exactly once, at creation or rotation; later reads omit them. Store it at that moment. This is the correct design and it is also the thing that surprises people at three in the morning, so it is stated here rather than left in a response description.
Deliveries you can inspect and replayWebhook deliveries
Deliveries are queryable records with their own error detail and a retry operation, so "did that event reach us" is a question you answer from your own code rather than by opening a support ticket.
Any language, no SDK dependencyPlain HTTP
It is HTTP with JSON and a bearer token, so JavaScript, Python, PHP, Go, C#, Ruby or a shell script all work without waiting for us to ship a client for your runtime. If you want a typed client, generate one from the OpenAPI document rather than depending on ours.

Getting started

A first hour that tells you whether to continue

In this order. Each step answers a question that would otherwise surface after you have committed.

  1. 01

    Read the contract before writing code

    Open the OpenAPI document and search it for the two or three operations your integration actually depends on. If they are not in there, you have saved yourself a week — and that is the point of publishing a generated spec rather than a feature list.

  2. 02

    Create a key and make one authenticated read

    A list call with a bearer token confirms credentials, scopes and your network path in a single request. Do this from the environment that will really run it, not from your laptop.

  3. 03

    Create something twice with the same idempotency key

    Send the identical create request twice with the same key and confirm you get one record and a replayed response. It takes two minutes, it tells you whether you will need your own deduplication layer, and it is worth running against any vendor you evaluate.

  4. 04

    Upload through a session, not through your server

    Create an upload session and transfer from the client. If your integration streams bytes through your own API, you have inherited a bandwidth bill and a timeout problem that neither of us needs.

  5. 05

    Register a webhook and break it on purpose

    Point an endpoint at a URL, store the signing secret at creation, then make it fail. Look at the delivery record, read the error, retry it. Knowing what a failed delivery looks like before production is the difference between an incident and a ticket.

  6. 06

    Check your plan, not the documentation

    Run the same suite on the tier you intend to buy. Feature-gated operations return a distinct not-available error, so an entitlement problem is easy to spot — but only if you look for it before launch rather than after.

Questions

Developer questions

Is there an OpenAPI specification?

Yes: /dev/api-v2/openapi.json, an OpenAPI 3.1 document generated from the API contract registry rather than maintained by hand, so it describes exactly the operations the v2 management projection defines. Point your client generator at that URL. The written v1 endpoint guides live separately under /dev and carry their own v1 notice, which keeps the two surfaces easy to tell apart: generate clients from the v2 document, and read a v1 guide only when you are maintaining an integration already built on v1.

What happens if a create request times out and I retry it?

You get the original response, not a second record. Create operations require an Idempotency-Key header and a duplicate request replays the first result. A key reused with different content returns a distinct idempotency-conflict error rather than failing ambiguously.

How do I know when processing has finished?

Long-running work returns an operation record you can fetch by id, list, or cancel, and webhook endpoints deliver events with an inspectable delivery log and a retry operation. You do not have to poll a collection on a timer and diff it to find out.

What do errors look like?

A consistent envelope with a code drawn from a fixed enum: authentication required, invalid API key, insufficient scope, permission denied, feature not available, limit exceeded, validation error, not found, conflict, idempotency key conflict, operation in progress, rate limited, provider unavailable and internal error. You switch on the code rather than parsing a message.

Which languages and frameworks are supported?

All of them, in the only sense that matters: it is HTTP with JSON and a bearer token. There is no runtime dependency on an official SDK, and if you want a typed client you can generate one from the published specification rather than waiting for us to ship one for your language.

Is the API available on every plan?

No. API access is not on the free tier, and several resource families — commerce and TV feeds among them — are gated above the entry tiers. Operations you are not entitled to return a feature-not-available error rather than a 404, so run your integration tests against the plan you intend to buy.

Can users upload directly from the browser?

Yes. Create an upload session and have the client transfer to it, so your API key never reaches the browser and the bytes never pass through your server. This is the recommended shape for any product with user-generated video.

Do you publish an uptime SLA?

Not on this page. An availability commitment is a contractual term rather than a marketing figure, so if your evaluation needs one, raise it with us directly and you will get the answer in writing, against the plan you intend to buy.

Read the contract before you take our word for any of this

Everything on this page is visible in the OpenAPI document linked from the API reference. Open it, search it for the operations your integration needs, and decide from that rather than from a feature list — including ours.

See the API referenceTalk to us