Key takeaways
- The core loop is: store a post + target time → a worker claims due jobs → call each platform’s API → record the outcome.
- OAuth token storage and refresh, not the UI, is where most scheduling apps lose the most engineering time.
- A platform-agnostic data model still needs an escape hatch for genuinely platform-specific fields (TikTok’s privacy level, Pinterest’s board id).
- Idempotency and exactly-once delivery are the two guarantees a job queue for publishing cannot skip.
Social media scheduling app development: the core data model
At minimum: a Post (caption, media references, owner), one or more Targets (which connected account, which platform), and a Schedule (a timestamp or an immediate flag). Keep Post and Target separate from the start — a post fanning out to five accounts needs five independent outcomes (one platform can fail while the other four succeed), and retrofitting that split after launch is a real migration.
A ConnectedAccount table holds the OAuth tokens (encrypted at rest) and the platform-specific account id. Never store raw platform tokens in the same table as user-facing data — a breach of one should not expose the other.
- Post — caption, media refs, owner, campaign (optional)
- Target — post id, connected account id, platform, per-platform overrides, status
- Schedule — type (now/at/range), timestamp(s), timezone
- ConnectedAccount — encrypted token, platform, external account id, health status
The job queue: the part that’s harder than it looks
A naive cron that scans "posts due in the next minute" every minute works at small scale and breaks in three predictable ways: it double-publishes if two workers scan the same window, it drops a post if the worker crashes mid-publish, and it can’t retry a single failed platform without re-running the whole post.
The fix is a real queue (Postgres row-locking with SKIP LOCKED, or a dedicated queue like BullMQ/Redis) where a worker CLAIMS a job before processing it — an unclaimed job stays visible to other workers, a claimed-but-never-completed job times out and returns to the pool, and each Target is its own job so one platform’s failure doesn’t block or retry the others.
Per-platform publishing: keep the differences at the edges
Each platform has genuinely different requirements — TikTok requires an explicit privacy level, Pinterest requires a board id, YouTube wants a title. Resist the urge to force every platform through one generic "caption + media" call; instead, keep a shared core (caption, media, schedule) and a per-platform "overrides" object that only that platform’s adapter reads. This is the same shape a production unified API uses — see the unified-API architecture guide for the worked example.
Media is its own subsystem: transcode once into whatever renditions each target platform actually requires (aspect ratio, codec, duration limits), not per-post — a piece of media posted to five platforms should be transcoded five times at most, once per real requirement, not five times per post if it’s reused.
OAuth, token refresh, and reauth — budget real time for this
Every platform’s OAuth implementation has its own quirks: token lifetimes, refresh mechanics, and what happens when a user revokes access from the platform’s own settings (your app finds out on the NEXT API call, not immediately, unless you’ve also wired a deauthorization webhook where the platform offers one). Build a health-check path from day one — a connected account should have a visible state (healthy / needs reauth / disconnected) surfaced to the user, not a silent publish failure discovered days later.
Idempotency and exactly-once delivery
A publish worker WILL be retried — a network blip, a process restart, a timeout waiting on a slow platform response. Without an idempotency key tied to the job, a retry can double-post. Store a stable key per (post, target, attempt-generation) and check it before calling the platform API a second time; if the platform itself supports a client-supplied idempotency key (rare, but some do), pass it through.
Build it or use an existing API
Everything above is real, ongoing engineering work — OAuth per platform, token refresh, media transcoding, a correct job queue, idempotency. If your product’s value is the scheduling workflow itself (not the publishing plumbing), building on an existing unified posting API removes all of it; if publishing infrastructure IS your product’s differentiator, build it, and budget for the parts in this guide, not just the UI.
FAQ
- What’s the minimum viable architecture for a scheduling app?
- A Post/Target/Schedule data model, a claim-based job queue (not a naive cron scan), one adapter per platform behind a shared interface, and encrypted OAuth token storage with a visible account-health state. Media transcoding and webhooks can come after the first working loop.
- Should I build my own OAuth flow for every platform, or is there a shortcut?
- Every platform requires its own OAuth app registration and consent flow regardless — there’s no way around that if you’re integrating platforms directly. Building on a unified posting API removes it entirely: you mint a connect link and the platform-specific OAuth happens behind that one flow.
- How do I avoid double-publishing on a worker retry?
- Give every publish attempt a stable idempotency key (e.g. a hash of the target id + a generation counter) and check it before calling the platform, and use a claim-based queue (row-locking or a real queue library) so two workers can never pick up the same due job at once.