A media workflow often starts with a URL. The next step needs an actual file: audio for transcription, a video for editing, or media in storage for a dataset. Connecting those two steps takes more than copying a link.
Tornado API is a managed media API that retrieves, prepares and delivers media to your workflows. You submit a supported source URL and choose the output you need. Tornado processes a job, reports its outcome and delivers the resulting file. The dashboard gives you a place to try that process, inspect jobs and follow usage before connecting your application.
The job behind a media URL
Consider an application that turns a customer's podcast episode into a searchable transcript. It needs to obtain the media, choose an audio format its transcription service accepts, receive the file and associate it with the right customer request. If the episode is unavailable, the application needs a useful result for that case too.
Tornado handles the media acquisition and preparation part of that workflow. Your application still decides which sources to process and what to do with the delivered files. Transcription, summarization, publishing and model training are downstream steps that you connect yourself.
That boundary is why we build the product around jobs. An accepted request is the start of the work. A completed job tells you the media has been delivered. You can inspect the result instead of assuming that an accepted URL became a usable file.
How we use the product
The dashboard uses the same media engine as the public API. When you submit a job there, you can inspect its progress, output and usage, then carry that understanding into an automated integration.
For a first workflow, start with one source you are allowed to process. Choose an output, wait for completion and open the resulting file. Check that your next tool can read it. The first-workflow guide follows this path from the dashboard to an API request.
This is also a useful way to evaluate a change. If your application needs audio instead of video, or a clip instead of a full file, test that request and inspect both the output and its usage before scaling it up. A smaller file can have a different billable basis, as explained in our usage guide.
What we take responsibility for
We provide the API, media processing, supported delivery integrations and job reporting. We maintain those parts of the product so your team can connect media to its own application without operating each processing step itself.
Your team chooses the sources, supplies any customer storage configuration, protects its API keys and decides who receives the outputs. Your destination and downstream services remain part of the complete workflow. A job can finish successfully while a later transcription or publishing step still needs attention.
What our product promise covers
A supported platform does not mean every URL on it is accessible. Source restrictions, removed content, unavailable formats and delivery permissions can affect a request. Our failure guide explains how to respond to those outcomes.
The rate, allowance and service commitments that apply to your account are shown in your dashboard and accepted terms. We do not ask you to infer them from a benchmark or an old blog article. Likewise, a delivery link is not a promise of permanent hosting: the storage guide separates access from retention.
Start with the result your application needs
Write down one source, one output and one destination. That is enough to make a useful first test. Once the delivered media works in your application, add automation, usage monitoring and a recovery path for failed jobs.
Open the dashboard to try your first media workflow, or read the API quickstart if you are ready to integrate.