Recurring Social Media Posts: Schedule Setup in 2026

Recurring social media posts need a rule that chooses eligible content at each scheduled time. In Uplonic, an upload schedule selects a video from a folder or a list of library video IDs. This guide uses the API to create a paused rule, inspect its next run, change its time zone and control activation. Saving the rule does not prove that a social network has received a post.

If the same source video will go to several networks, start with the guide to adapting one video for Shorts, TikTok and Reels. A recurring schedule cannot make an unsuitable video acceptable to another platform.

What you will achieve and what you need

The result is a saved, inspectable recurring rule that you can pause or activate. You need a workspace API key with write access, the API base URL, library video IDs belonging to that workspace and a connected destination channel. Keep the key on your server or in a trusted API client.

The examples below are JSON request bodies. Replace VIDEO_ID and CHANNEL_ID with your workspace's identifiers, and send the API key in the x-api-key header. The demonstrated source mode is keys, meaning an explicit video list. Folder selection is a separate supported mode and is not the path tested here.

Create the rule in a paused state

Send POST /schedules with this body. The weekly expression means Monday at 18:00 in the named time zone; that is example configuration, not a recommendation about audience activity. Cron syntax is defined by node-cron's documentation, checked 2026-10-17.

{
  "name": "Weekly archive",
  "sourceMode": "keys",
  "videoIds": ["VIDEO_ID"],
  "platforms": ["youtube"],
  "channels": ["CHANNEL_ID"],
  "cronExpression": "0 18 * * 1",
  "timezone": "Europe/Budapest",
  "excludeRecentDays": 30,
  "isActive": false
}

The development test returned HTTP 201 with a rule ID, isActive: false and a nonempty nextRunAt. Store the returned rule ID. The repeat-exclusion value of 30 days is our tested example setting, not a platform limit; set it for your own pool of reusable content. A pool that is exhausted by that exclusion window can produce a skipped run.

Check the time zone and next run

Request GET /schedules and find the returned ID. Confirm the source IDs, channel IDs, cron expression, timezone and nextRunAt. Interpret the timestamp in the selected time zone before enabling the rule. The posting schedule generator can help draft a calendar, but its output does not create or activate this rule.

To change the zone, send PUT /schedules/RULE_ID with {"timezone":"UTC"}. In our dev check, the API recalculated nextRunAt. Changing the zone changes the meaning of the same wall-clock expression; it is not just a display preference.

We also checked the installed cron parser with a daily 18:00 rule in Europe/Budapest. The next instants were 2026-10-24T16:00:00.000Z and 2026-10-25T17:00:00.000Z: the local hour stayed the same while its UTC equivalent changed. These are measured preview results from 2026-10-17, not observations of production delivery. The cron-parser project documents its time-zone and daylight-saving support.

Activate, pause and verify the result

After checking the source and destination, update the rule with {"isActive":true} at PUT /schedules/RULE_ID. Pause it with {"isActive":false} through the same endpoint. Our activation test used an annual expression whose next run was safely in the future, then paused and deleted the rule. That tested registration and removal of the scheduled task without initiating publication.

Keep the distinction between the rule and its work: a rule's last-run success can mean it created a publishing request. Inspect that request's destination results before calling the post published. Pausing a rule prevents future selections; it should not be treated as cancellation of publishing requests already created by earlier runs.

The implementation registers future cron executions when rules load; it does not implement a historical replay loop for every missed recurring tick. Do not assume an outage will automatically produce all missed posts. Review existing requests before manually triggering anything. These implementation observations were checked in the scheduler source on 2026-10-17.

If the setup does not work

Before activating a real campaign, inspect your source files with the video specification checker and confirm the destination connection. The tested setup above establishes rule management; a live publishing check remains your separate acceptance step.