Publora API: access, scheduling and failure handling
Publora includes REST API and MCP access on its free Starter plan. It is suitable for evaluating a small automated publishing workflow, but the free allowance is restrictive: three connected accounts, 15 posts a month, three pending posts and a seven-day scheduling horizon. The current pricing page excludes X from Starter. Pro adds webhooks and removes the advertised queue and scheduling-horizon caps; Agency adds client workspaces and team roles. Publora pricing.
The practical distinction is between getting a request accepted and confirming that each destination published it. An integration needs to handle both.
What the API connects to
Publora lists ten publishing destinations: LinkedIn, X, Instagram, TikTok, YouTube, Facebook Pages, Threads, Bluesky, Mastodon and Telegram. Authentication uses the x-publora-key header against https://api.publora.com/api/v1. Users connect their social accounts in Publora; the integration uses the resulting connection IDs. Keep the API key on your server rather than in browser-delivered JavaScript. API overview, Create Post reference.
Check the exact format and account type you intend to publish. The presence of a network does not mean every network-specific field is interchangeable. In particular, the documentation describes Pinterest as connect-only, not a supported publishing destination. Create Post media rules.
A complete request-to-publication workflow
Build the integration around five stages:
- List connected accounts and retain the selected connection IDs. Check the connection state before building a queue.
- Prepare the copy and required media. For public HTTPS assets,
mediaUrlscan attach media and schedule in one call. For local files, create a draft, obtain the upload URL, upload the file, then schedule it. - Send the intended UTC time. Save the returned
postGroupId, effectivescheduledTimeand any warnings. - Track the group and individual destination results until publication succeeds or a failure needs attention.
- Record the final outcome in your own system, including which destinations require recovery.
Instagram, TikTok and YouTube require media at the scheduling stage. A media-free draft is allowed, but scheduling that same post without media is rejected. Also, attaching media to an already scheduled post can return it to draft, so an asset-replacement workflow must verify scheduling again afterward. Create Post reference.
Connection status, account listing and Pro webhooks are described in the API overview. For a campaign tracker, keep separate fields for editorial approval, API acceptance and publication. Collapsing those into one “done” flag makes failures harder to spot.
Four limits to budget separately
Scroll sideways to compare every column.
| Limit | What it means for an integration |
|---|---|
| Plan allowance | Starter has account-wide monthly and pending-post caps; Pro's documented fair-use allowance is 5,000 monthly posts per connection |
| Scheduling horizon | Starter cannot load a month's entire future calendar at once |
| Public-media ingestion | 60 media URLs per fixed hourly window; throttling returns 429 and Retry-After |
| Destination-platform rules | Network-side limits can still reject publication after Publora accepts the job |
Publora says it currently does not enforce a general requests-per-minute limit. That should not be read as unlimited media ingestion or an exemption from platform rules. Its rate-limit table excludes X on Starter, while a later bullet on the same page says Starter has no platform restriction. The pricing page also excludes X; budget for Pro if X is required, and resolve the conflicting help text before relying on a free X integration. Rate limits.
For a simple workload calculation, 40 posts with two separately ingested image URLs each create 80 media-URL ingestions. At the documented 60-URL hourly cap, they cannot all be ingested in one fresh window. Use the returned retry timing rather than immediately replaying the whole batch. This is capacity arithmetic, not measured throughput.
Retries should not create duplicate posts
Scroll sideways to compare every column.
| Outcome | Appropriate response |
|---|---|
| Request times out | Retry the same logical create with the same idempotency key and unchanged body |
409 IDEMPOTENCY_IN_FLIGHT | Wait briefly and retry the same request |
422 IDEMPOTENCY_KEY_CONFLICT | Check whether the body changed; do not reuse a key for a different post |
partially_published | Inspect each destination before planning recovery |
| Invalid input or permissions | Correct the cause rather than repeatedly submitting it |
A group can publish successfully on one platform and fail on another. Blindly creating the whole group again risks duplicate successful posts. Prefer machine-readable error codes for handling and display the destination-specific failure to the operator. Error handling.
One remaining timing uncertainty matters: the Create Post page still describes an August 25, 2026 strict-mode transition in future-tense wording, while the error guide notes that production configuration can override that date. Send future timestamps and inspect returned warnings instead of depending on a grace period for past times. Scheduling-time behavior.
Publora is worth evaluating when you want hosted publishing endpoints without operating the scheduler yourself. Compare that responsibility split with the Postiz review and Postiz versus Publora, particularly if owning the deployment matters more than reducing integration upkeep.