How to Stream to YouTube, Facebook, TikTok and Twitch at the Same Time?

To stream to YouTube, Facebook, TikTok and Twitch at the same time, you send one broadcast from your encoder and let DCAST copy it to each platform. The path runs in this order: create your DCAST account, check what your plan allows, add each platform as a destination in a restream flow, optionally control that flow from your own code, optionally connect an AI assistant, and embed the player on your own website. After the steps, this guide covers the decisions that sit beyond the product, such as where the copying should happen, platform rules and stream keys.

Step 1: Create your DCAST account

Open the sign-up page and fill in the form with your email address, a password and the same password again in the confirmation field. The form refuses an empty field, two passwords that do not match, and a password shorter than eight characters, so read the message, fix that field and submit again. When the account is created, you see a confirmation message.

Use an email address you read regularly and a password you do not reuse anywhere else. Whoever gets into this account can start broadcasts to your channels, so treat the login with the same care as the stream keys you are about to collect from each platform.

Step 2: Check your plan and its restream limit

Before you build a lineup, find out which plan your account is on. Click your avatar in the top right corner and choose Billing; the coloured plan badge next to the logo opens the same page. In the Available Plans row you see FREE, STAR, PRO and VIP side by side, and the card whose button reads Current Plan is your plan. Read the feature list on that card, because it names the streaming limits and tools that apply to you.

How many destinations can run at the same time depends on your plan. The plan settings carry a separate cap for each of FREE, STAR, PRO and VIP, and on PRO it is six. Count the platforms you want against that cap before an event, and remember that a custom address for any other service is a destination too.

If the cap is lower than your lineup, change plans from the same Billing page. Click the button on the plan you want and a checkout window opens with the plan name at the top. Then pick how you want to be billed and complete the payment in the window that opens. When it closes, the dashboard shows the new plan already applied, and the card of that plan reads Current Plan.

Step 3: Create a restream flow and add each destination

In the dashboard, open Restream from the navigation and click Create Restream or Create Flow. Give the flow a clear name, such as Sunday Service or Product Launch, and choose the source type: an existing DCAST stream or a direct RTMP input. If you pick an existing stream, select it from the list, then click Save. The flow appears in the Restream section, and you open it to add destinations. If your source stream is missing from the list, create it first in the Streams section and come back.

Now open the flow. The panel is called Channels, not Destinations, so click Add Channel and select the platform type. For YouTube and Twitch, paste the stream key from the creator studio of that platform. For Custom RTMP, paste both the server URL and the stream key. Give each destination a recognizable name, for example YouTube Main Channel, click Save, and repeat for every platform you want to reach.

The settings list YouTube, Twitch, Facebook, Instagram, TikTok and Kick as destinations, plus a custom address for any other service. The dashboard help names YouTube, Twitch, Facebook and Custom RTMP in its platform selector, so if a platform you need is not offered there, add it as a custom destination with the server address and key that platform gives you.

The settings protect you from a half-finished setup. A destination without a stream key, or a custom destination without its address, cannot be switched on until the missing field is filled in, and the settings tell you exactly which field that is. Platforms with a known ingest address only need your stream key. If you clear the key of a destination, that destination drops out of the active list instead of failing in the middle of a broadcast. A destination you switched off stays off even when every field is filled in, while one you complete and switch on becomes active right away and stays saved for your next broadcast.

Two failures are common at this stage. If a platform rejects the stream key, generate a fresh key on that platform, because keys can expire or be reset. If you added the same platform twice, delete the duplicate destination before going live. After that, run a short test so you know every destination really receives video.

Step 4: Control restreams from your own code

If you run events on a schedule, or you want your own dashboard to manage the flow, the same work can be done through the partner API. Its restream operations let your code create a restream, list your restreams, read one, update one and delete one. Further operations start and stop a restream, start and stop its input, update a single destination, rotate the key of a destination, and fetch the encoder addresses, the preview address and the preview stream. One more operation lists your restream accounts.

The source you name when you create a restream, such as RTMP, SRT or WebRTC, is the source that is stored and answered back. To restream one of your existing broadcasts, you link that broadcast as the source, and a broadcast of another account is refused. A request that links a broadcast and also names a different source protocol is refused too, so your code never gets a restream it did not ask for.

Destinations behave the way they do in the dashboard. A destination address that points into a private network is refused before anything is saved. When you update a restream, a switch you send is written as you sent it, and an update that leaves the switch out keeps what was stored. A destination missing its stream key or its address cannot be stored as switched on.

When you read a restream, each destination shows whether it is switched on, its last error and the moment that error happened. A read-only key sees whether each destination is switched on but not the error text, because that text can carry the address of the destination. If a start cannot go ahead, the answer names each switched-on destination and the field it is missing, and it tells nothing switched on apart from nothing filled in. Use that answer to repair the destination instead of retrying blindly.

Keep your API key on your server, never in a web page or an app that your viewers download. If you build a dashboard that only displays your restreams, give it a read-only key.

Step 5: Optionally connect an AI assistant

This step is optional and is not needed to go live. The DCAST connector is an MCP server for video that connects an AI assistant such as Claude to your DCAST account. Because it gives another tool a way into your account, the part worth knowing before you connect is how to take that access away again.

When you remove the connector in your DCAST API keys, it leaves your list of keys. A token the connector received before the removal is refused from that moment, even if it had not expired yet, and a newer token cannot reopen the connection either. To connect again, you approve the access in DCAST once more. Removing the connector also closes the permission requests it still had open, so an old approval cannot widen a new connection. An ordinary API key that you delete, by contrast, is removed outright.

Ask your assistant to tell you what it is about to change before it changes it, so you stay in charge of your library. After a session, look over what the assistant changed, the same way you would check the work of a new colleague. If you suspect that someone else used the connection, remove it first and connect again afterwards with a fresh approval, and remove any connection you no longer use so no forgotten assistant keeps a way into your account.

Step 6: Embed the player on your own website

Social platforms are rented space, so give viewers a place of your own as well. You can place the player of your videos and broadcasts on your own website with a short embed code. For a recorded video, open the video in your library, click Share, then click Embed, copy the embed code and paste it into the HTML of your page. Make sure you copy all of the HTML, not just the address, or the embedded video will not load.

Through the partner API, the same is done with two operations: one gets the embed of a stream and one gets the embed of a video. Before you share a video, check that its status is Ready and that its visibility suits your audience, then open the link in a browser as a visitor to confirm playback.

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. A list entry can cover every subdomain of a site with a wildcard, so one line serves the whole site, and clearing the list opens your player to every website again. Only you can change the list for your content, and the rule follows the owner of each video or broadcast, so one list covers your uploads, your live events and their chat.

Decide which goal matters more. 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. Malformed entries such as a bare wildcard or a full page path are rejected before anything is written, so a typo cannot open or close your player by accident.

Decide what to send from home and what to leave to the service

The most important decision is where the copying happens. If your encoder sent a separate stream to every platform, your home connection would have to carry all of them at once, and it rarely can. Send one stream from your encoder and let the service copy it to each platform. Your upload then stays stable however many destinations you add, and a problem on one platform does not force you to touch the encoder settings.

Then check each platform's own rules before the first broadcast. Vertical video, stream keys and live length are handled differently by every platform, and a format that suits one audience may not suit another. Decide in advance which platforms get your main framing, and read the rules of TikTok and Twitch separately rather than assuming they match YouTube or Facebook.

Test every destination before an important event

Test each destination with a short private broadcast before an important event, because every platform has its own rules for new streams. A fresh channel may behave differently from an established one, and you want to learn that on a quiet afternoon rather than in front of your audience. During the test, open every platform as a viewer and confirm that video and sound arrive, then read the destination settings for any field they still name as missing.

Finally, protect the keys. Anyone who holds a stream key can broadcast to that channel, so never paste keys into chats or screenshots, and generate a fresh key on the platform whenever you suspect one has leaked. Update the destination in your flow afterwards, run another short test, and only then go live for your audience on every platform at once.