Postiz · Rate Limits

Postiz Rate Limits

Postiz applies a single global per-hour request limit that, as documented, applies only to the create-post endpoint: 90 requests per hour, raised to 100 on Postiz Cloud. The limit counts API requests, not published posts — one createPost call can schedule many posts across many channels, which is the documented way to maximise throughput. The limit is a single instance-wide value and does NOT tier by subscription plan; plans tier on channel count and monthly post volume instead. Self-hosters set their own value with the API_LIMIT environment variable.

Postiz Rate Limits is the machine-readable rate-limit profile for Postiz on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 5 rate-limit definitions, measuring requests, bytes, posts, and channels.

The profile also includes 4 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Social Media, Scheduling, Open Source, Content, and Marketing.

5 Limits Throttle: 429
Social MediaSchedulingOpen SourceContentMarketingRate LimitingQuotasThrottling

Limits

Create Post Requests Per Hour (self-hosted default) instance
requests
90
Counts API requests, not posts. Batch multiple posts into one request to maximise throughput.
Create Post Requests Per Hour (Postiz Cloud) instance
requests
100
Single global value for the whole instance; does not tier by subscription plan.
Request Body Size request
bytes
50 MB
Exceeding it returns 413. Pre-upload media instead of base64-inlining images.
Monthly Posts (Cloud plan quota) account
posts
per plan (400/month on Standard; unlimited on Team and above)
Commercial plan quota, not a per-hour API throttle. See plans/postiz-plans-pricing.yml.
Channels (Cloud plan quota) account
channels
per plan (5 / 10 / 30 / 100)
Number of connectable integrations. No channel cap on self-hosted.

Policies

Configurable Self-Hosted Limits
Self-hosted operators set the per-hour limit with the API_LIMIT environment variable.
Backoff Strategy
Clients should implement exponential backoff with jitter on HTTP 429; no Retry-After is returned.
Batch To Maximise Throughput
The limit counts requests. Schedule many posts in a single createPost call rather than one call per post.
Idempotent Deletes
A 404 on a delete means the post is already gone and is safe to ignore.

Sources