Rate limits

When you connect a channel (LinkedIn, WhatsApp, email, and so on), Customermates talks to that provider through Unipile. Every provider enforces its own request limits, and exceeding them can get the underlying account throttled or suspended. To stay within safe bounds, Customermates applies a conservative request budget per channel and pauses before a provider would push back.

A paused sync is expected behavior: it keeps the connected account within provider limits and resumes on its own.

How do the limits work?

Limits are configured in the Unipile dashboard and enforced by Unipile. They apply per connected account at three levels at once:

• Per endpoint: a cap on each individual operation (listing chats, reading messages) over a rolling minute and day. These are the read limits below.
• Per sensitive method: a stricter cap on riskier operations (profile lookups, sending a message or a connection request). These are the sensitive limits below.
• Per account: an overall cap across every call for the account.

When a window is full, further calls are rejected until it rolls over.

What are the read limits per provider?

Read operations sync history. They are set higher than writes because reads rarely trigger a provider ban.

LinkedIn stays the most conservative because its automated-activity detection is the strictest. Some values are shaped by the provider's own ceilings: social channels cap the per-minute read limit at 50, email channels at 100, and the daily limit moves in steps of 30 (so a target of 500 is applied as 510). Telegram and the email providers do not expose a separate daily read limit.

What are the limits for sending and profile lookups?

The riskier operations stay conservative regardless of the read budget: profile lookups (which providers treat as scraping-sensitive) and any send action.

Operations without a row here, such as sending a LinkedIn message or InMail and LinkedIn Sales Navigator searches, still fall under the per-endpoint and per-account caps and return the same rate-limit message when a window is full.

What happens when a limit is reached?

Further calls for that account are rejected until the window rolls over, and the action tells you how long to wait. Sending a message or starting a conversation shows:

Other actions word it differently:

• Resync thread, older messages loading at the top of a conversation, and media in a message: "This channel hit its rate limit. You can try again in 2 minutes." with Learn more.
• Refresh in the Inbox: "Some channels hit their rate limit. Try again in a few minutes."
• Moving an email to another folder: "Stopped filing into {folder} because the provider is rate limiting." with the waiting time for the rest.

The waiting time in the message comes from the Retry-After value of the rate-limited response Unipile returns; without one, the message falls back to 60 seconds and reads "in 1 minute". Customermates does not retry the action for you: the waiting time is only a hint, and you can retry once the indicated window passes. Nothing is lost in the meantime. Over MCP and the REST API the call fails with the same message and waiting time: the REST API answers with HTTP status 429, and MCP returns a failure of kind rate_limit whose issue in _meta.failure has customCode: "unipileRateLimit".

Link: the Inbox page, /inbox. Mate: navigate and highlight_element with nav-inbox; Refresh and Resync thread are not highlight targets, so Mate names them.

Does the history import resume by itself?

Importing a full message history can be large, roughly one request per conversation. If a limit is reached mid-import, the background importer pauses and resumes automatically when the window frees up, with no action needed on your part; a wait longer than ten minutes defers the import to a later sweep. With Manage on Inbox messages, scrolling to the top of a conversation or pressing Resync thread fetches older messages from the provider, and both count against the same limits; new activity arrives in real time over webhooks.