Rate Limits

Rate limits across all TRUE endpoints — per-tool, per-tier, retry semantics, and the 429 contract.

What this is

TRUE applies rate limits per endpoint, per token, and per user. The goal is graceful degradation under contention rather than hard outages. Most surfaces include a soft-limit warning before the hard cap, so a well-behaved client can back off before being rejected.

Per-tier quotas

Tier	Auth	Default RPM	Burst	Concurrent SSE
Anonymous	none	20 / minute	40	1
Authenticated	Wallet JWT	120 / minute	240	4
Developer	API key	600 / minute	1200	16
Partner	API key	6000 / minute	12000	64

Burst is the short-window cap; sustained traffic is rate-limited to the per-minute number.

Per-tool / per-endpoint limits

Some endpoints have tighter limits than the bucket suggests:

Endpoint / tool	Limit
`chat.send`	60 / minute / token
`swap.quote`	120 / minute / token
`swap.submit`	30 / minute / wallet
`mcp.tools/call`	100 / minute / token (overall), per-tool sub-caps below
`get_price`	120 / minute / token
`getMemecoinOverview`	60 / minute / token
`webhooks.register`	10 / minute / token
`quotes.price`	60 req/sec (public), 600 req/sec (partner)

Retry semantics

When you exceed a limit, the response is 429 Too Many Requests with a Retry-After header in seconds. SSE streams emit a structured event: error frame with code: rate_limited and the same retry hint. Clients should:

Honor Retry-After exactly. Don’t add jitter that ignores the hint — the server is telling you when to come back.
Apply exponential backoff only when Retry-After is missing.
Use a per-token token-bucket on the client side to stay below the limit instead of being told off by a 429.
Watch for the X-RateLimit-Remaining header and slow down when it drops below 10% of the bucket.

Soft-limit warnings

When you cross 80% of your bucket, responses include X-RateLimit-Warning: soft_cap. SSE streams emit a warning frame with the same code. Use these to back off proactively rather than waiting for the 429.

429 vs graceful degradation

Read endpoints (get_price, get_news) prefer graceful degradation: when the per-tier cap is exceeded, the response is served from a stale cache with a stale-while-rate-limited flag rather than failing. Write endpoints (webhooks.register, swap.submit) hard-reject with 429 and Retry-After.

For Partners

Elevated quotas are available on the partner tier. Onboarding includes a per-endpoint cap negotiation and a dedicated SLA. Request via [email protected] with a description of your traffic profile (steady RPM, burstiness, peak hour).

For Developers

429 contract

HTTP/1.1 429 Too Many Requests
Retry-After: 12
X-RateLimit-Limit: 120
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1745924712
Content-Type: application/json

{
  "error": {
    "code": "rate_limited",
    "message": "Rate limit exceeded for endpoint mcp.tools/call",
    "retry_after_s": 12
  }
}

Detecting in SSE

event: warning
data: {"code":"soft_cap","remaining_pct":18,"endpoint":"chat.send"}

event: error
data: {"code":"rate_limited","retry_after_s":7,"endpoint":"chat.send"}

After the rate-limited error frame, the server closes the stream. Clients should reconnect after retry_after_s.

Safety, limits, failure modes

Per-wallet swap caps exist independently of the per-token RPM and are designed to slow MEV / drain attempts.
Burst caps reset on a sliding window — about 30 seconds for most endpoints.
Retry storms from misbehaving clients trigger temporary bans starting at 5 minutes and escalating.
Stale-cache mode on read endpoints can serve up to 30 seconds old data while rate-limited; respect the flag downstream.