Skip to main content
Tied doesn’t publish a rate-limit contract. It does enforce real limits, though, keyed by IP or by account depending on the endpoint. The numbers below are what you’ll actually hit.
These are the enforced limits. They apply in production only.

​
What’s throttled

If you embed the web chat widget, three more throttles apply to traffic your visitors generate rather than to anything your server calls. All three are keyed by visitor IP: The first is the one worth knowing about: six new conversations per IP per 12 hours. Visitors behind a shared NAT — an office, a school, a large mobile carrier — share that budget. If that is a problem for your traffic shape, talk to support rather than working around it client-side. The global per-IP number is generous enough that a normal integration won’t come near it. The ones you can realistically hit are contact search, the reports endpoints, and — if you’re pulling transcripts or pushing attachments in bulk — those two hourly account-level throttles.
Separately, the dashboard’s own sign-in, password-reset, and MFA endpoints carry their own tight, IP- and email-keyed throttles — as low as 5 attempts per 5 minutes. Those exist for brute-force protection on the login page, aren’t part of the data API, and aren’t meant to be called programmatically. If an integration is hitting them, something’s calling the wrong endpoint — see Authentication.

​
What a throttled response looks like

A tripped throttle returns 429 with a plain-text body, not the JSON error shape used everywhere else in this API:
There’s no Retry-After header. The underlying library supports one, but it’s off by default and nothing in the app turns it on. Don’t build a client that waits on a header it isn’t going to receive — back off on a fixed or exponential schedule instead.

​
Sensible client behavior

With no Retry-After to read and no published SLA to design against precisely, build for the general case:
1

Back off on 429, not just on 5xx

Treat a 429 as “slow down,” not “retry immediately.” Exponential backoff with jitter, starting around a second, is the standard shape — and it’s the only shape that makes sense without a Retry-After value to anchor on.
2

Don't parallelize list scans

Firing 200 concurrent contact-search requests at one account trips the 100/minute throttle long before it hits any real page boundary. Paginate serially, or cap client-side concurrency well under the limits above.
3

Batch report pulls

Polling /api/v2/accounts/{account_id}/reports on a schedule? Pull a wider window less often rather than a narrow window constantly — both the per-user and per-account throttles are keyed per minute.
4

Cache what isn't paginated and doesn't change every second

Agents, teams, and canned responses aren’t paginated and aren’t likely to change between polls. Don’t refetch them on a tight loop just because the call happens to be cheap to write.

​
Next

Errors

Status codes and body shapes for everything that isn’t a 429.

Idempotency

What’s safe to retry after a backoff — and what isn’t.