To schedule a YouTube playlist rotation with Node-RED, use a timezone-aware flow to decide when to act, then make playlist changes through the YouTube Data API. Node-RED handles the schedule and orchestration; OAuth-authorised API calls do the editing.
First define exactly what “rotation” means for your channel. There is no universal rule: you might add one new video at a chosen local time, remove the oldest item before adding another, or change a playlist according to a weekly timetable.
Define the rotation before building the flow
Write the rule in plain language before creating nodes. For example: “At 06:00 India time each day, add the next approved video to the devotional playlist, and remove the oldest item only if the playlist has reached my chosen size.” That statement identifies the schedule, the source of the next video, the destination playlist, and the condition for deletion. The size is your editorial choice, not a YouTube or Node-RED default.
Decide what counts as the “next” video. You could keep an ordered list of video IDs in a file or flow context, derive the next item from a manually maintained queue, or use a separate playlist as a source. Each approach needs a rule for what happens at the end of the list: restart from the beginning, wait for someone to add more videos, or stop and alert you. Do not let an accidental empty value choose the next upload.
Also define what happens when the target item is already present. YouTube documents a duplicate-video error for playlist insertions in some circumstances. A safe policy is to check the destination list before inserting and treat an existing video as a completed or skipped action, depending on your rule. This is particularly useful when your flow is restarted or a retry follows an uncertain response.
Make deletion an explicit editorial decision. Some channels only add items and allow a playlist to grow. Others remove a particular old item after confirming that a replacement was added. If you delete first and the subsequent insert fails, you may leave the playlist shorter than intended. For a small rotation, inserting and verifying first, then deleting the selected old entry, is often easier to recover from. If ordering matters, account for the fact that a playlist’s contents and positions may change between calls.
If your goal is to keep a video playing continuously rather than merely change the playlist’s contents, playlist rotation alone may not control a currently running live broadcast. The relationship between your broadcast and playlist playback is a separate design question. For the broader distinction between playlist looping and a live programme, see how a radio-station playlist can loop without gaps.
Choose a scheduler that respects local time
A repeating interval and a wall-clock schedule are not the same. “Every 24 hours” can drift relative to a local clock if the flow is delayed or restarted. “At 06:00 in Asia/Kolkata” expresses a local-time intention. Choose which one your channel actually needs, then record the intended timezone alongside the schedule so a future maintainer does not have to guess.
Node-RED can orchestrate a schedule in a flow. A simple timer may be sufficient for a short-lived test, but production use benefits from an explicit schedule, visible state and a clear way to change or disable it. The Node-RED Flow Library description for cron-plus documents cron and date schedules, dynamic control, timezone support and persistent schedule state. Package features and releases can change, so check the current documentation before relying on a specific behaviour.
Set a region-based timezone when the rule is tied to local time rather than hard-coding an offset. Offsets do not express daylight-saving changes in regions that observe them. Cron-plus documents daylight-saving handling: for fixed-time schedules, a repeated local time runs once, while a scheduled time skipped during a forward clock change runs as soon as possible after the transition. Verify current scheduler documentation and test the intended behaviour if that matters to your channel.
For a channel in India, Asia/Kolkata is a straightforward region timezone selection. If your audience, operator or editorial schedule is elsewhere, use the relevant region instead of assuming the computer’s timezone is correct. A Node-RED host may run with a different system setting from the timezone you intend, and a deployment moved to another machine should not silently change the rotation hour.
Keep the trigger separate from the editing logic. The schedule node should emit a clear event; a later part of the flow can check whether the run is enabled, whether a prior run is still in progress, and whether the necessary playlist and video IDs are present. This makes it easier to test the API calls manually without waiting for the next scheduled time.
Authorise access to the YouTube API
Playlist editing requires permission to act on the YouTube account that owns or can edit the playlist. The YouTube Data API getting-started guide explains API setup and authorisation. For writes, use OAuth rather than treating an API key as permission to edit a user’s playlist. The insert and delete method references list the OAuth scopes they accept; choose the least broad suitable scope and review the current reference for your use case.
OAuth adds work that a read-only prototype can conceal. Your flow needs a secure way to obtain and renew credentials, and you need to know what happens when consent is revoked or a token can no longer be refreshed. Keep client secrets and refresh tokens out of debug messages, exported flow files shared publicly, and ordinary logs. Restrict access to the Node-RED editor and its credential store as part of your operational setup.
During setup, authorise the Google account that actually has the necessary playlist access. A playlist ID copied from a URL is not proof that the account can modify it. Test a read operation against the intended playlist before allowing the scheduled flow to write. If the playlist belongs to a Brand Account or another managed channel, check which identity is being authorised and whether it has the required access.
Separate configuration from logic. Store the target playlist ID, timezone, approved video queue and rotation policy in clearly named settings rather than scattering them through function nodes. This reduces the chance that a test flow edits a production playlist simply because one ID was overlooked. Keep a clearly labelled test playlist for initial insert and delete checks.
The playlist implementation guide is useful context for the API’s playlist model. It does not remove the need to review each method’s current scope and request requirements before building your own flow.
Know which ID each playlist operation needs
A playlist contains playlist-item resources. Each item associates a video with a playlist and can carry information such as its position. The identifier of that playlist item is not the video ID. This distinction is central to a rotation that removes an existing entry.
To add a video, playlistItems.insert requires the destination playlist ID and a video resource ID in the request body. The method reference describes the request fields and OAuth requirements: playlistItems.insert. To remove a specific entry, playlistItems.delete takes the playlist-item ID, not the video ID: playlistItems.delete. The playlistItems resource reference explains the returned resource fields.
A practical flow therefore needs to retain both kinds of identifier. When it lists the target playlist, save each item’s playlist-item ID for a later delete and its associated video ID for comparison with your queue. Do not rename both fields simply to id; give them names such as playlistItemId and videoId so a later function node cannot silently pass the wrong one.
If you are deciding whether to remove an old video, use the listing response to identify the exact entry that matches your policy. Do not assume the first item is oldest unless your flow’s ordering rule and the API response establish that. If the same video can occur in more than one relevant context, match using the playlist-item record you intend to remove, not a guessed video identifier.
These details matter even for a small channel. A successful list call proves only that the flow can read a playlist. It does not prove that a delete will use the right identifier or that an insert is permitted. A useful test logs the chosen action and target identifiers, while avoiding credentials and other sensitive data.
Verify a node’s write support before relying on it
Node-RED’s community Flow Library includes node-red-node-youtube. Its public listing is version 0.0.5 and describes nodes for listing channel, playlist and playlist-item information. That description establishes listing capabilities; it does not establish support for inserting or deleting playlist items. Do not infer write support from a node’s name, old examples, or the fact that it can read playlist data.
If you want to use a community node, verify the exact write operations you need against its current documentation and maintained code, then test them against a non-production playlist. Check how it handles OAuth scopes and token renewal, whether it exposes API error details, and whether the release is maintained. A node that lists items but cannot mutate them may still help with one stage of a flow, but it is not a complete rotation solution.
The alternative is to call the YouTube Data API from Node-RED using authenticated HTTP requests. That makes the request method, URL, body, token handling and response visible in the flow, but leaves more implementation and error handling to you. A verified node can reduce request plumbing, but only if its write support and credential behaviour meet your needs. Compare both routes on the features you have confirmed rather than assuming either is simpler in every respect.
| Route | What you gain | What you need to verify or build |
|---|---|---|
| Community YouTube node | Potentially less request plumbing for operations it actually supports | Confirm insert and delete support, OAuth handling, error visibility and maintenance status |
| Authenticated API requests | Direct control over the documented request and response | Configure OAuth, construct requests and handle response codes and retries |
| Basic timer pattern | A simple trigger for a controlled experiment | Timezone behaviour, restart behaviour, persistence and protection from overlapping runs |
| Timezone-aware scheduler node | Explicit schedules and documented timezone features | Current package behaviour, deployment state and the local-time rule you need |
The package’s public description does not establish a current, verified write workflow. Treat that as a boundary in the available evidence, not as proof that no version or fork can write. Use the API directly or verify the precise node behaviour before you make it responsible for unattended changes.
Build and test the flow in stages
A maintainable flow can be read as a sequence: schedule trigger, configuration check, playlist listing, policy decision, optional insert, optional delete, and a result log. Keep these stages distinguishable. If a single function node hides all of the logic, the next person may struggle to tell whether an unexpected change came from the schedule, the selected video or an API request.
Start by triggering the flow manually and reading the target playlist. Confirm that the response contains the playlist-item IDs and video IDs you expect. Next test an insert with a known, approved video on a test playlist, then list the playlist again and verify the new item. Only after that should you test a delete, using the playlist-item ID returned from the list response. Avoid using your live audience-facing playlist as the first place to discover a field-mapping error.
Then add the policy logic without enabling the regular schedule. For a queue-based rule, the decision stage should select one known next video and record how the pointer or queue advances. Decide whether to advance the queue only after a successful insert or also after a confirmed duplicate. If the flow advances on any error, one temporary authorisation failure can skip an item permanently.
Before enabling unattended runs, check that the scheduler emits the expected local time, that a Node-RED restart does not produce an unintended burst of actions, and that a slow API response cannot start a second run while the first is still working. If schedule state is persistent, understand what it restores and what it does not. Persistent scheduling does not automatically make the playlist edits themselves transactional.
For an always-on channel, separate content rotation from the method used to keep the broadcast live. Node-RED can change playlist contents while another workflow or playback arrangement keeps a live stream going; the two jobs should not be conflated. If your aim is to change the video in a live broadcast rather than edit a playlist, the guide to switching videos in a running YouTube stream addresses that different operational problem. Likewise, the choice of host is a separate trade-off; the comparison of Mac mini and VPS running costs can help frame that question without making either device intrinsic to playlist rotation.
Handle failures, duplicates and uncertain outcomes
A scheduled flow should assume that an API call can fail. The YouTube API documentation describes authorization failures, missing IDs or resources, duplicate playlist videos, unsupported operations and maximum-item conditions. Read the current method references for exact response details, since API behaviour and quotas can change. Log enough information to diagnose a run: schedule time, intended operation, relevant target IDs and response status. Never log OAuth tokens.
Treat an ambiguous result differently from a confirmed failure. If the request times out after being sent, you may not know whether YouTube applied the change. Blindly repeating an insert can create a duplicate or return a duplicate-related error. Before retrying, list the playlist and compare its current state with the intended state. If the requested item is already present, record that the desired state is reached rather than blindly sending the same write again.
Prevent overlapping actions with a simple in-progress guard or another explicit concurrency rule. This matters when a request takes longer than expected, or when a manual test coincides with a scheduled run. A second run should either wait, exit with a visible “already running” result, or follow another documented policy. It should not independently choose and remove an item based on stale playlist data.
Quota is also part of the design. As documented by Google on 3 October 2026, a playlistItems.insert call costs 50 quota units and a playlistItems.delete call costs 50 quota units. Google’s YouTube Data API guide reports 10,000 default daily units combined for other endpoints, and says default quota may change. Check the live API quota guidance and your project’s quota console before deployment; do not assume those figures remain unchanged. Avoid unnecessary polling or repeated writes when one scheduled list-and-decide cycle will do.
If an operation fails, preserve enough state to recover deliberately. Record the selected video, the intended removal and the stage reached, then alert yourself through a channel you actually monitor. A flow that logs a red status only in a Node-RED editor left closed overnight is not a useful alerting plan. For persistent operation, decide who checks a failure and how they will restart or reconcile the rotation.
Keep the live-channel workflow separate
A playlist rotation is a content-management action, not a promise that a 24/7 live broadcast will remain uninterrupted. The API can alter playlist membership, but your live output has its own playback, encoding and connection dependencies. Make the boundary explicit in your diagram and your recovery notes: one section owns playlist state; another owns the broadcast.
That separation is useful when diagnosing an overnight issue. If viewers report that the same song stayed on air, first establish whether the playlist changed as expected and whether the broadcast source consumes those changes. If the playlist did change but the live output did not, the fault may be in the playback path rather than the API call. The guide to streaming royalty-free chillhop from a Windows PC covers a different source-and-playback setup; it should not be mistaken for a Node-RED playlist-editing recipe.
If maintaining the broadcast source itself is the part that keeps your computer running overnight, StreamNeo addresses that specific burden by running an uploaded video as a YouTube live stream with your computer switched off. It does not replace the playlist rule or make YouTube API authorisation unnecessary for a Node-RED workflow.
For your own flow, write down three separate checks: did the schedule fire at the intended local time, did the playlist operation reach the intended state, and did the live programme reflect the change? That small distinction helps you find the right failure point rather than changing OAuth settings when the playback source is actually the issue.
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
Can Node-RED schedule playlist edits without a computer running?
Node-RED needs a host that remains available for its flow to run. The scheduler only triggers the workflow; it does not itself keep a computer or deployment online. Choose a suitable always-available host and test what happens after a restart before relying on the schedule.
Does node-red-node-youtube support playlist writes?
Its public Flow Library description documents listing channel, playlist and playlist-item information, not a verified write workflow. Do not assume it can insert or delete items based on its name or version. Confirm the precise operations and test them against a non-production playlist, or make authenticated API requests directly.
Which ID do I use to delete a video from a playlist?
Use the playlist-item ID returned for the entry you want to remove. The video ID identifies the video itself and is not interchangeable with the playlist-item ID required by playlistItems.delete.
Is there one correct rotation policy for every channel?
No. Choose whether your rule adds, removes, reorders or skips items, and define how it handles duplicates and an exhausted queue. A devotional channel with a daily featured bhajan may need a different rule from a local news loop.