How to Host Videos for a Fire TV App

A Fire TV app needs two things that are usually confused with each other. It needs somewhere the video files are stored, transcoded and played back from, and it needs a catalogue the app can read so it knows which titles exist and where to fetch each one. DynTube covers the first, and supplies a feed for the second. The app itself — and everything Amazon requires around it — is yours to build.

This article covers the decision: which part of a Fire TV project DynTube takes off your plate, which part it does not, and what to verify before you put an app in front of Amazon. The exact dashboard fields, error codes and troubleshooting steps live in the DynTube documentation linked further down.

What DynTube provides

• Hosted playback assets — you upload a source file once, and DynTube transcodes it into adaptive renditions that a player can switch between as the viewer's connection changes during playback.
• A stable MRSS (Media RSS) feed URL that returns the published videos in one project you select, as RSS/MRSS XML served as application/rss+xml.
• Per-item metadata your app can render: title, description, link, publication date, media URL, file size, duration in seconds, thumbnail, and the managing editor value you configured as the author.
• Channel-level values taken from the feed record: the channel title from the feed's Title field and the channel language from its Language Code.
• A per-request response, rendered from your current data at the moment the feed is fetched, ordered by the feed's sort order and capped at 1000 items.

Connect the feed to your Fire TV app

Use the DynTube feed as the catalogue input to the Fire TV application you build with Amazon's current tooling and documentation:

• The Fire TV app itself, built or ported with a framework Amazon supports for Fire TV.
• Playback behaviour inside the app: how a title is opened, how playback state and resume are handled, and how errors are shown when a media URL cannot be played.
• Sign-in and entitlement behaviour, if your catalogue is not fully open.
• Amazon developer account setup, app configuration, store listing and submission.
• Testing on the Fire TV devices and versions you intend to support.
• Any Amazon catalogue or launcher integration you want, which is a separate process from the app feed — see the last section.

Prepare the video project

A Fire TV feed covers exactly one DynTube project, and only the videos in it whose status is Published. That makes the project the unit of curation, and it is worth getting right before you create the feed at all:

• Put the titles you intend to ship in the app into their own project, so a draft or an internal upload elsewhere in the account can never reach the feed.
• Publish only the titles you want visible. Anything left unpublished is excluded, and a project with no published video does not render a feed.
• Check each title and description as they will appear on screen — the feed carries them through, and a TV interface gives long strings far less room than a web page.
• Check that every title has the thumbnail you want, since the feed passes one thumbnail per item to your app.
• Play each title back before you wire it in, so the feed is not the place you discover a failed or missing output.

Adaptive playback helps here: the player moves between renditions as the connection varies, rather than committing to one bitrate for the whole play. It reduces stalls on a variable connection; it does not eliminate them, and no hosting provider can promise that on a network it does not control.

Create the DynTube Fire TV feed

In the DynTube dashboard, open More tools → Fire TV (/feeds/fire-tv), then Add Fire TV Feed (/feeds/fire-tv/add). The form asks for:

• Title — required. It becomes the channel title in the feed XML.
• Project — required. The videos in the project you select are the videos in the feed.
• Managing Editor — required for Fire TV, and format-checked: an email address followed by the editor name in parentheses, such as [email protected] (Editor Name). Anything else is rejected on save.
• Language Code — required for Fire TV. Use an ISO language code such as en-US.
• Sort Order — optional. Newest first, oldest first, name A–Z or name Z–A, defaulting to newest first.

The feed's public URL is built from its feed key, not its internal id, and is the value you paste into your app's configuration:

https://api.dyntube.com/v1/feeds/fire-tv/<YOUR_FEED_KEY>

The full walkthrough, including what each field ends up as in the XML and how to copy the URL from the feed row, is in the DynTube documentation:

• How to Add Your DynTube Fire TV Feed to an Amazon Fire TV Channel — /docs/tv-apps/how-to-add-your-dyntube-fire-tv-feed-to-an-amazon-fire-tv-channel
• How to Create a Video Feed for Roku & Fire TV — /docs/videos/how-to-create-a-video-feed-for-roku-and-fire-tv

How updates work

The XML is not a stored file that DynTube maintains and pushes out. It is rendered from your current data each time the feed URL is requested, which changes what you should expect after an edit.

• Adding, removing or editing a video changes what the next feed request returns. A change is eligible to appear in the next successfully rendered response; whether it does still depends on processing and publication state, and on any caching in front of the feed.
• Your app shows the change at its next successful feed fetch. The app and the platform control that schedule, not DynTube.
• CDN, proxy or platform-side caching between your app and the feed can delay it further.
• DynTube never pushes an update to an app, and there is no synchronisation callback to subscribe to.

If your app looks stale, request the feed URL directly first. That one check separates a DynTube-side question from an app or caching question, and they have completely different fixes.

Validate before submission

Request the feed yourself before it goes anywhere near a submission:

curl -i https://api.dyntube.com/v1/feeds/fire-tv/<YOUR_FEED_KEY>

1. The URL returns XML, with your feed Title as the channel title.
2. The item count matches the published videos in the selected project — no extras, nothing missing.
3. Each item carries the title, description, thumbnail and media URL you expect.
4. The media URLs actually play, not just resolve.
5. An unknown feed key and a project with no published videos both return 400 Bad Request. Those two cases are deliberately indistinguishable from outside, so check the feed key and the publication state together rather than assuming which one you hit.
6. Playback works on the Fire TV devices and versions you plan to support, not only in a desktop player.
7. Your app handles the unhappy paths: navigation with an empty or partial catalogue, sign-in where you require it, and a clear error state when a fetch or a play fails.

Fire TV feed versus Amazon catalog integration

These are two different pieces of work, and conflating them is the most common way a Fire TV plan slips. The DynTube MRSS feed is an app feed: your app reads it to populate its own catalogue. It is not an ingestion channel into Amazon's systems.

Having titles appear in Amazon's own surfaces — Universal Search and Browse, and launcher placements — is an additional Amazon process with its own requirements, its own catalogue ingestion and its own testing. It is developer work you undertake with Amazon, and Amazon now describes its older Catalog Data Format integration as legacy, directing new catalogue integrations to EMBER. Check Amazon's current documentation rather than any third-party walkthrough, including older versions of this page:

• Get started with Fire TV app development — https://developer.amazon.com/docs/fire-tv/get-started-with-fire-tv.html
• Getting started with Universal Search and Browse — https://developer.amazon.com/docs/catalog/getting-started-universal-search-and-browse.html
• Catalog data format schema reference — https://developer.amazon.com/docs/catalog/data-format-schema-reference.html

A short decision checklist

1. Do you have, or will you build, a Fire TV app? If not, the feed has nothing to feed, and the app is the first decision, not the hosting.
2. Is your Fire TV catalogue one curated project's worth of published videos? That is the shape the feed supports.
3. Do your titles, descriptions and thumbnails read well on a television screen?
4. Does your plan include TV app feeds, and does your account permission allow managing the account? The Fire TV feed pages are gated on both.
5. Have you requested the feed URL, played the media, and tested on the devices you intend to support?
6. Do you need Amazon catalogue or launcher placement as well? If so, budget that as separate Amazon work with its own timeline.

If that lines up, the hosting side is the straightforward part: upload into one project, publish what belongs in the app, create the feed, and point your app at the URL. The documentation linked above has the exact steps, including the plan and permission requirements for the feed pages. If you are not sure your plan covers TV app feeds, check the pricing page or ask us before you plan the app build.