Rate limits | ParsChat API

Pre-release v1, published 2026-09-14. This page commits to the shape of the API, not to a date. We will build exactly what is documented here. The shape can still change until 2026-10-14; after that, changes follow Versioning and stability.

The banner comes off one page at a time as each route goes live. While it is here, build against the contract and assume the route is not callable yet.

Limits are enforced per key, and every response carries your current state:

X-RateLimit-Limit
X-RateLimit-Remaining
X-RateLimit-Reset
Retry-After            (on 429)

Your limit

The limit is a plan dimension set by sales, not a constant in the API.

Plan	Limit
	2,000 / hour
	3,000 / hour
Partner (contact-us tier)	2,000 / hour, raised on request

Layer	Set by	Scope
Plan default	Sales, per plan	Every account on that plan
Per-account override	A ParsChat developer	One account, for a recorded reason

You start at the same ceiling as the entry paid plan and are raised once your real traffic is known. Volume is discovered after you integrate, not when the contract is signed, and raising your ceiling should not require editing a plan that other customers share.

The override is staff-only. It is not in this API and not in your panel, so ask your account manager. It records who set it and why.

Exceeding the limit queues, it does not drop

This matters more than the number, because it changes what you have to build.

When a robot exceeds its hourly limit, outbound automated Instagram replies are queued and sent later. Nothing is discarded.

	If we dropped	What we actually do
Your obligation	Detect the drop, re-send, build your own queue	None. We hold it
End user’s experience	No reply at all	A later reply
Your customer	Silently loses conversations	Sees slower replies under load

Why queue rather than reject: the requests being limited are automated replies to a real person who messaged a shop. Dropping one costs a customer conversation, and you could not meaningfully retry it anyway. By the time you noticed, the moment has passed.

The queue holds for two hours

A queued reply is held for at most 2 hours. After that it is dropped and recorded.

A reply is only worth sending while the person is still in the conversation. Past a couple of hours the end user has moved on. An answer arriving then reaches someone who has forgotten the question, and makes your product look erratic rather than slow.

What you see


Your own API calls	`429 rate_limited` with `Retry-After`. You can meaningfully retry these
Outbound automated replies	Never rejected. Queued and sent when capacity frees

So 429 always means “you are calling us too fast”. It never means “your customer’s reply was thrown away.”