Home / Docs / Rate limits

Rate Limits

How Postifys publishing concurrency, disk guards, and social-platform rate limits affect API clients - without inventing undocumented quotas.

Last updated: 2026-07-24 · Technical source: live Postifys API behavior and API reference

Quick answer: Postifys pricing is based on connected profiles (not a public per-day post quota). Publishing is still protected by concurrency, disk, and social-platform rate limits. Design clients to handle queueing, retries, and provider throttling.

Billing vs request limits

  • Plan sizing is $2 per connected profile / month (see Pricing).
  • There is no separate public “N posts per day” quota documented as the product’s billing unit.
  • Backend protections still exist against flooding and overload - treat the API as a production service, not an unbounded firehose.

Operational publishing limits (Postifys side)

These are current operational controls that affect how fast jobs move, not marketing promises:

  • Per-platform publish lanes - Facebook, Instagram, YouTube, Pinterest, LinkedIn, and TikTok each process async publish jobs with lane concurrency of 1.
  • Media download concurrency - concurrent remote downloads are capped (default max 2) so large files do not starve the host.
  • Temp-media disk guard - publishing can refuse new work when free disk under temp media is below the configured minimum (default 10 GB).
  • Media queue - POST /api/media/queue returns 202 for async preparation; poll status instead of assuming immediate readiness.

Social platform rate limits

Meta, Google/YouTube, Pinterest, LinkedIn, and TikTok enforce their own quotas and abuse protections. A healthy Postifys key does not override those limits. When a provider throttles or rejects, the failure reason appears in Post History / the JSON error message - back off and retry later.

Client guidance

  1. Publish important jobs sequentially per destination account when possible.
  2. Prefer final media URLs; use proxy/Drive flows only when needed (Media requirements).
  3. On failure, read error.message / history before blind retries (Errors).
  4. For bursts, expect queueing on Postifys lanes and possible provider throttling.
  5. Watch /health and Status during widespread failures.
Idempotency: A dedicated public idempotency-key API is not documented yet. Avoid double-submitting the same large upload while a job is still queued/processing; use history/status to confirm completion.
Errors & recovery Create a post
← Webhooks Pricing