Run your videos and live broadcasts from your own site through the DCAST API

If your product already has its own pages, users and database, sending people to a separate video dashboard is a step backwards. You want your own code to add videos, list them and start broadcasts while visitors stay on your site. This article walks you through that setup with the DCAST API, the decisions to make first and the failures to check for before launch.

Connect your site to DCAST once through the API; after that your own code adds new videos and creates live broadcasts, with no visit to the DCAST dashboard.

Keep the key on your server and decide who owns what

Before you write any upload code, decide where the API key lives. Keep the API key on your server and never place it in a page that your visitors load. Anyone who opens the page source or the network log can copy a key shipped to the browser, and from then on they can act as your account. Store it in an environment variable, keep it out of version control, and let your browser talk only to routes on your own backend. Those routes should check that the visitor is allowed to upload before they call the video API.

A video added through the API belongs to the account that owns the API key. If several projects share one key, all their videos land in one library and you cannot tell whose content is whose. Where you can, use a separate key for each project, so you can rotate one without breaking the others and so a leak has a smaller reach.

Upload a video from your own code

When you add a video through the API you give it a title, a file name, a file size and a visibility such as public.

Each upload request returns the address your site sends the video file to, and a status address that tells your site when the video is ready to show.

The file itself is sent to the returned upload address with a PUT request.

Decide who sends the bytes. Sending from your server is the simplest path to log and retry. Sending straight from the visitor's browser spares your backend from relaying large files, but then you must be sure the upload address is safe to expose to that visitor, and you must handle a tab that closes halfway through. Pick one approach per project, write down why you chose it, and test it with a throttled connection.

The storage space for the file is claimed for your account at the moment the upload is requested, before the first byte of the file moves.

Read the answer to the upload request before you start sending bytes, and stop if it is an error. Pushing a large file to an address you never confirmed wastes your visitor's time and your bandwidth. Show a plain message when the request is refused, and avoid retrying in a tight loop, which only repeats the same refusal.

Measure the file size on your side and send that exact number. A mismatch between the declared size and the real file is the kind of bug that shows up only with large uploads, so try one small file and one file of several gigabytes before you trust the flow.

Wait for the status address before showing a video

Your site should not show a player the moment the PUT finishes. The status address from the upload request is how your site learns that the video is ready to show, so store it next to the video record in your own database.

Poll with growing intervals, for example every few seconds at first and then every thirty seconds, and stop after a sensible limit. Save the last known state with a timestamp so a server restart does not lose track of a video. When the limit passes, mark the video as delayed in your interface instead of showing a spinner that never ends.

Each video in the list shows its status, for example ready, together with the address of its player page.

Use that list as a safety net. A nightly job that compares your database with the list catches any video whose status check was missed, for example because your server was down during the wait. Fix the mismatch by updating your own record, not by uploading the file again.

Build a gallery from your library

Your site reads the list of your videos with the status of each and fetches the ready player code for any of them, so it can build its own video gallery from your DCAST library.

The list of your videos contains only the videos of the account that owns the key, never the videos of another account.

The list is paged and tells you the total number of your videos, so your site can page through a large library.

Do not fetch the whole library on every page view. Cache the list on your server for a short time, show visitors only videos whose status is ready, and use the total count to draw page links. Clear the cache when your own code adds a video, so the new item appears at once.

Asking for the player code of a video that belongs to another account is answered as not found. Treat that answer as an ordinary case in your code. When it appears for an identifier you stored yourself, first check which key your environment is using, because a wrong key is a likelier cause than an outage.

Place the player on your page

The player code comes as a plain address, as an iframe snippet and as a responsive version that scales with the page.

The player code is an iframe that you place on your own page.

Choose by layout. Use the responsive version in article pages and card grids, where the width changes with the screen. Use the plain address when you want to build the iframe yourself, for example to add a title attribute that helps screen readers. Check the page on a real phone before launch, because a fixed-size frame is the commonest reason an embedded video looks broken on mobile.

You can place the player of your videos and broadcasts on your own website with a short embed code.

By default the embedded player works on any website, so a partner or a fan can share your content without asking you first.

If you want control, list the domains where your player may appear, and every other website is refused.

Decide the list by your goal. Restrict the list when you sell access through your own site and want the player to appear only there. Leave the list empty when your goal is reach, because every copy of the embed code then works for whoever pastes it.

Start live broadcasts from your code

Your site creates a live broadcast through the API and receives the addresses to publish to, together with the player code for the page that shows the broadcast.

A new broadcast comes with an RTMP address, an SRT address and, where it is available, an HTTPS address for WHIP.

A live broadcast created through the API is stored for your account and has its own embed address for the player.

Pick the publishing address that matches your encoder. RTMP is accepted by nearly every desktop encoder and hardware box, SRT copes better with a lossy network when your encoder supports it, and WHIP lets a browser publish without extra software. If you have no strong reason to choose otherwise, start with RTMP and move to the others once your first broadcast works.

Before a real event, run a ten-minute rehearsal created by the same code path you will use on the day. Check that the player on your page shows the picture, that the sound is present, and that your encoder reconnects after you unplug the network for a few seconds. Then store the broadcast identifier so your support team can find it later.

Run these checks before launch

Work through this short list in order. First, search your built pages and your browser network log for the API key; it must appear nowhere. Second, upload a small file, a large file and an unsupported file, and confirm that each ends in a state your interface can explain. Third, open the gallery as a logged-out visitor and check that unfinished videos are hidden. Fourth, request a player for an identifier that does not exist and confirm that your page degrades gracefully instead of showing an empty frame.

Once these checks pass, your visitors see one site, your code owns the workflow and the video platform stays in the background. Start with one upload and one gallery page, then add broadcasts when the first part runs quietly.