To connect IRL Pro to a YouTube channel without sharing your password, configure a streaming destination and enter its complete publish URL in the app. The documented IRL Pro workflow uses RTMP or SRT; it does not describe signing into Google or linking a YouTube account inside IRL Pro.
Your Google password and your broadcast key are different credentials, and neither belongs in an ordinary app password field. If a separate streaming service offers YouTube authorisation, that account connection happens through that service’s own documented flow, not by assuming IRL Pro has the same feature.
Why you should not share your password
A Google password gives access to more than one live stream. It can be tied to account settings, channel management and other Google services, so typing it into an unfamiliar app or sending it to another person creates risk well beyond configuring a video feed. Do not send it in chat, email or a support message, and do not enter it in a field presented as a server URL, stream key or destination credential.
OAuth is a different arrangement. An application sends you to a Google authorisation page, where you sign in with Google and decide whether to grant the requested access. The application receives authorised access rather than your password. Google’s YouTube Live API OAuth documentation explains that OAuth 2.0 lets users share specific data while keeping their usernames and passwords private.
This does not mean every app that can stream to YouTube needs to connect your Google account. An encoder can be given a destination URL and a broadcast key generated or supplied elsewhere. In that arrangement, the encoder sends video to the destination; it is not necessarily logging into your channel or managing your YouTube account.
A broadcast key is still sensitive. Enhanced IRL’s link security guidance warns that a link containing access details can let someone broadcast as the channel owner. Treat a key like a credential: do not post it in a public screenshot, reuse it carelessly, or leave it exposed after troubleshooting. If you believe it has leaked, use the relevant service or YouTube controls to replace or revoke it, then update the destination settings that depend on it.
Choose and configure a streaming destination
Before opening IRL Pro, identify the service that will deliver your video to YouTube. That could be YouTube’s own live setup, or a separate relay service that provides a destination for an encoder. The exact screens differ, but the working detail you need is a publish URL, sometimes called a stream URL, server URL or ingest URL. The service may also ask you to choose a protocol and configure a stream key.
In the service dashboard, create or select the intended YouTube destination. Check that it is the correct channel and event before copying credentials. If you are using a service that connects accounts through OAuth, confirm that you are on the service’s own account-connection screen and that the browser redirects to Google for consent. Do not infer an account connection from the fact that a destination URL is available.
For a workflow involving a relay, the service may retrieve a YouTube broadcast key after the channel is authorised. A URL/key combination may then be formed for the encoder. The documented Enhanced IRL workflow is one example: its dashboard has a separate YouTube account connection, and it can populate the broadcast key for use in its destination setup. That is a service feature, not evidence that IRL Pro itself has a YouTube OAuth connection.
If you are building a direct YouTube destination instead, follow YouTube’s current live setup and encoder guidance to obtain the appropriate URL and key. Google’s YouTube Live API authentication guidance describes user authorisation for API access and notes that live functionality has eligibility and approval conditions. Check YouTube’s current official requirements for your channel rather than treating a successful app configuration as proof that the channel is enabled for live streaming.
Keep a small private record of which destination belongs to which channel or event. This is useful if you operate more than one channel, such as a devotional stream and a local news loop. A note like “Channel A — evening bhajan — SRT destination” can prevent pasting the right-looking URL into the wrong channel. Do not include the actual key in a shared planning document.
Select the matching RTMP or SRT protocol
IRL Pro and the destination service must use the same protocol. If the service is configured for RTMP, choose RTMP in IRL Pro; if it is configured for SRT, choose SRT. A complete URL cannot compensate for a protocol mismatch: the receiving service is listening according to its selected transport, and the sender must speak that same transport.
The Enhanced IRL guide for broadcasting with IRL Pro documents configuring an RTMP or SRT destination and entering its publish URL in IRL Pro. Follow the current instructions in the service you are actually using; menu names and available choices can differ. Do not assume the app will detect or convert the protocol automatically just because the address was pasted correctly.
| Setting | What to match | What to check before sending |
|---|---|---|
| RTMP | RTMP in the service and RTMP in IRL Pro | The complete destination address includes the required key when the service’s format calls for it |
| SRT | SRT in the service and SRT in IRL Pro | The complete publish URL includes the stream ID or key in the format supplied by the service |
The key’s location differs. In the documented setup, the SRT stream ID carries the key, while an RTMP URL ends with the key. That is why copying only the first part of an address can break the connection even when the host name looks correct. Use the complete publish URL exactly as the service presents it; do not try to reconstruct it from memory or combine pieces from different destinations.
If a screen offers additional transport settings, such as latency or encryption parameters, use values provided by the destination service rather than guessing. This article’s central check is protocol agreement and a complete URL; it is not a basis for inventing service-specific tuning values. If the service’s instructions and the app’s options do not line up, pause and verify the supported protocol with their official documentation.
Copy the complete publish URL
Copy the whole URL from the destination screen, including its protocol prefix and every character after it. For RTMP, a service may include the broadcast key at the end of the URL. For SRT, the key may appear in the stream ID. In either case, the field you paste into IRL Pro must contain what that destination expects, not merely a base server address.
Take care with characters that are easy to miss on a phone: punctuation, slashes, question marks, equals signs, and upper- or lower-case letters. Avoid adding spaces before or after the URL. If you must transfer it between devices, use a private method and remove any temporary copy from a shared clipboard or note when you are finished. A screenshot is not a safe substitute for a private credential transfer.
Check whether the service labels separate fields for a server URL and a stream key, or supplies one complete publish URL. The documented IRL Pro approach described here is to paste the complete publish URL into the app’s URL or server field. Do not split it unless the service and app explicitly ask for separate values. Conversely, do not paste a value labelled only as a key into a URL field and expect the receiving service to fill in the missing address.
Before leaving the dashboard, confirm you copied the destination for the right channel and the right protocol. If the service has a copy button, use it, then verify the protocol prefix and the presence of the expected key or stream ID without exposing the full value to other people. For practical context on keeping a continuous broadcast operating after setup, see how to keep a Hindi music stream playing during an internet outage; it addresses continuity rather than account linking, but the distinction between a configured destination and a live broadcast matters there too.
Enter the destination details in IRL Pro
Open IRL Pro and add or edit the streaming destination using the controls described in the app’s current guide. Choose the same protocol selected in the service dashboard, then paste the complete publish URL in the URL or server field. Save the destination before starting a test, so you can review the selected protocol and destination if the connection fails.
Do not look for a Google password field as part of this URL setup. The destination workflow is about where IRL Pro sends its video. It does not, by itself, establish that the app has permission to read or manage your YouTube account. If you see a field whose purpose is unclear, check the app or destination service’s official instructions instead of entering account credentials to see what happens.
When testing, check both ends: IRL Pro should show that it is sending, and YouTube or the destination service should show that a broadcast is arriving at the intended place. A sender-side “connected” message is not by itself confirmation that the right channel is receiving the stream. Check the channel, title and stream status before telling viewers that the broadcast is live.
If no video arrives, work through the basics in order. Confirm the protocol matches, confirm the full URL was copied, and verify that the destination key or stream ID has not changed. Then check the network connection and whether the YouTube channel can currently go live. Change one setting at a time; replacing several values at once makes it harder to identify the actual cause.
If you are moving from this mobile encoder setup to a longer prerecorded broadcast, the destination is only one part of the operating plan. Our guide to scheduling prerecorded videos for an always-on YouTube channel in OBS covers a different way of sending a continuous programme. It is not a step in IRL Pro setup, but it can help you decide whether a mobile live encoder or a scheduled playback workflow fits the job.
Publish URL and YouTube account linking are different
These terms describe separate operations. A publish URL tells an encoder where to send video and, depending on its format, includes or carries a broadcast key. Account linking authorises a service to access a YouTube identity or data through a consent process. One configures a video path; the other grants account permissions.
| Question | Publish URL setup | Account authorisation |
|---|---|---|
| What is being connected? | The encoder to a receiving destination | A service to a YouTube account or its permitted data |
| Where does a secret appear? | In the URL or stream ID as a broadcast key | On Google’s sign-in and consent pages, not in an app’s ordinary password field |
| What does it allow? | Sending a stream to the configured destination | The specific access approved in the authorisation request |
| Does one replace the other? | No; an encoder still needs a destination | No; OAuth does not automatically configure an encoder URL |
For IRL Pro, the reviewed setup instructions document the destination URL and protocol steps. They do not show a Google OAuth screen inside the app. So the precise answer to “Does IRL Pro connect to YouTube with Google?” is that the documented connection method is a publish URL configured in the app; the available instructions do not establish native Google account linking in IRL Pro.
This distinction also explains why a broadcast key must remain private even when you never share your password. OAuth keeps the password from being passed to the service, but a key may still authorise someone to send a broadcast as the channel owner. Limit access to both credentials, but do not confuse their purpose or assume protecting one makes the other harmless.
What Enhanced IRL’s separate OAuth flow does
Enhanced IRL documents an account-connection feature in its own dashboard. Its instructions direct a user to the platform connections area, start a YouTube connection, send the user to YouTube to approve access, and return to the Enhanced IRL dashboard. The service can then sync the connection and retrieve the broadcast key for its documented workflow. See Enhanced IRL’s platform connection guide for its current steps.
That feature belongs to Enhanced IRL’s service. It should not be described as an IRL Pro feature: the documented IRL Pro guide covers selecting RTMP or SRT and entering a complete publish URL, while the OAuth directions concern the separate dashboard. IRL Pro can act as the encoder using destination details without the reviewed material showing that it performs the account authorisation itself.
If you use Enhanced IRL’s flow and no broadcast key is available, its documentation says to create a YouTube stream first and then sync the connection so the service can retrieve the key. Follow the service’s current instructions and check that the stream belongs to the intended channel. A permission approval and a usable stream destination are related steps in that service’s workflow, but they are not the same step.
Google’s YouTube Live API documentation also sets boundaries on the authorisation model. It describes user authorisation and states that service accounts are not supported for connecting a YouTube account through that API. It also explains that channel live eligibility matters. These are reasons to consult the current official documentation if a permission flow fails; they are not grounds to promise that any particular account will be approved or enabled.
The practical rule is straightforward: enter your Google password only on a genuine Google sign-in page, reached as part of a service’s explicit authorisation flow. Enter the publish URL only in the encoder destination field. Keep the broadcast key private even after OAuth succeeds, because account authorisation does not make that separate sending credential safe to disclose.
A desktop or cloud-based always-on workflow may suit a different kind of channel than a mobile IRL stream. If you are comparing those approaches, running a continuous YouTube stream with a Google Cloud VM explains the operational considerations of another setup. It does not change how IRL Pro’s documented URL workflow works, but it can help frame the choice between a mobile encoder and a stream intended to run when no phone operator is present.
When you have confirmed which destination and operating approach fit, use the next step that matches your channel rather than sharing credentials to save time.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does IRL Pro have a documented Google account-linking feature?
The reviewed IRL Pro setup guide documents configuring an RTMP or SRT destination with a complete publish URL. It does not document a Google OAuth account-linking feature inside IRL Pro. Do not attribute another service’s authorisation flow to the app.
Can I use IRL Pro without giving it my Google password?
The documented destination setup uses a URL rather than a Google password. If a separate service requires YouTube account authorisation, use its explicit OAuth flow, where you approve access on Google’s page. Never type your Google password into a server, URL or stream-key field.
Is my broadcast key the same as my password?
No. Your password signs you into Google, while a broadcast key is a separate credential used to send a stream. Keep the key private because someone who obtains it may be able to broadcast as the channel owner.
What should I check if IRL Pro does not send video?
First make sure IRL Pro and the destination service use the same protocol, then confirm you pasted the complete URL including the required key or stream ID. Verify the intended channel and that the channel is currently able to go live. If those checks do not resolve it, consult the current IRL Pro and destination-service documentation rather than guessing at credentials.