Social Media Scheduling API: A Complete Guide

Publishing immediately through an API is simple. Scheduling is where the interesting problems are, because a scheduled post is a promise about the future and the future contains daylight saving, outages and posts you change your mind about.

Time zones: pass one explicitly

The most common scheduling bug is a post that drifts by an hour twice a year.

A scheduled time needs two things: the instant, as an ISO-8601 timestamp, and the zone it was expressed in, as an IANA name like America/New_York.

await bp.posts.create({
  content: 'Morning update.',
  channels: [{ channelId: 1, platform: 'linkedin' }],
  status: 'scheduled',
  scheduledAt: '2026-04-10T14:00:00Z',
  timezone: 'America/New_York',
});

Storing only a UTC instant is fine for a one-off. It’s wrong for anything recurring, because “every weekday at 9am local” is a different UTC instant before and after a daylight-saving change. The zone is what makes that correct.

Never store a raw offset like -05:00 as a substitute for a zone. Offsets change; zones don’t.

Model more than two states

A post is not just scheduled or published. Build for at least:

• draft, created but not queued
• scheduled, queued for a time
• processing, sent to the platform, outcome unknown
• published, confirmed live
• failed, with a reason
• partial, published to some targets and not others

The two people forget are processing and partial.

processing exists because several platforms accept a post and publish it asynchronously. A 200 is not a publish, and the real outcome arrives later.

partial exists because one post usually targets several platforms. If three succeed and one fails, neither “published” nor “failed” is true, and forcing it into either produces a UI that lies to the user.

What happens when a platform is down

Design for it, because it happens.

Transient failures should retry with backoff. A platform returning 503 for two minutes shouldn’t lose the post.

Retries must be safe. A create that timed out may have succeeded. Retrying blindly duplicates the post, which is worse than the original failure. Check before retrying.

Permanent failures shouldn’t retry at all. An expired token or an invalid caption won’t fix itself, and retrying just burns quota and delays the notification.

Somebody has to be told. A failed scheduled post at 3am is silent unless you made it noisy. Webhooks are the right mechanism.

Editing and cancelling

A scheduled post is a promise you may need to break. Your integration should support changing the time, editing content, and cancelling outright.

Note that platforms differ on whether they allow this once they hold the post, which is one reason scheduling in your own layer and submitting at the last moment behaves better than handing the platform a future-dated post.

Queue slots versus explicit times

Two scheduling models, and both have a place.

Explicit times are what you want when a post has to land at a moment: a launch, an event, a coordinated announcement.

Queue slots are what you want for a steady drip. You define a posting cadence and the next post takes the next free slot, so you’re not choosing timestamps for every post in a batch.

For bulk work the second is much less tedious, and it’s the model that makes “queue thirty posts” a sensible operation rather than thirty decisions.

Recurring schedules

Distinct from a scheduled post. A recurring schedule is a rule that keeps producing posts on a frequency: daily, weekly, biweekly or monthly.

Two things to design for. The zone matters even more here, for the daylight-saving reason above. And media attached to a recurring post has to be kept rather than cleaned up after publishing, because the schedule needs it again next time.

Plan limits

The short version

Pass an IANA time zone alongside every scheduled timestamp, especially for anything recurring. Model processing and partial as real states, because asynchronous publishing and multi-platform posts make both genuinely happen. Retry transient failures with backoff, never retry a create blindly, and use webhooks so a 3am failure isn’t silent.