Why am I getting rate-limit errors?

A rate-limit error means your system called one Wetel operation more times inside its window (usually 60 seconds) than that operation allows, and Wetel answered with an error that has the meaning of HTTP 429. Limits are counted per calling address, not per API key, workspace or user, so every customer your backend serves from one server shares one count: wait for the window to pass, retry, and spread or queue your calls.

Think of a car park gate that lets thirty cars through a minute. It does not care whose cars they are. If all your customers arrive through your one gate, they queue together.

Which operations have a limit?

Only the operations listed on the rate-limiting page have one; everything else is unthrottled today. A few examples, as documented:

The start-a-conversation limit is a deployment setting, so an environment can be tuned differently; the limit that applies to you is the one in the error you get back.

Sending a message in a conversation, ending one, and startSession, sendMessage and endSession have no enforced limit today. The docs are clear that this is a current state, not a guarantee, so build backoff around them anyway.

Why does my whole backend hit it at once?

Because the count belongs to the address the request reaches Wetel from. If your servers, or your users behind one office network, share an address, they share a bucket. The trade is deliberate: one abusive caller cannot use up a workspace’s allowance for everyone else.

generateText is the one exception. It has a second, separate ceiling per workspace, so a backend relaying many users through one address is not held to the per-address figure alone. Both ceilings must pass.

What should my backend do?

Back off, retry after the window, and put your own fairness in front. In practice:

• Wait, then retry. The rate-limiting page says to back off and retry after the window. On the speech routes, a quota error carries a Retry-After header: wait the stated seconds.
• Queue rather than burst. If one outside event fans out into many calls, the docs ask for your own backoff and retry whether or not a limit is enforced today.
• Apply your own per-user limit. If one of your users can starve the others of a shared bucket, the docs recommend a per-user fairness limiter on your side.
• Do not poll the expensive read. agentActivitySummary is meant to be fetched on load and on focus.
• Load tests: if you legitimately need more than thirty starts a minute, the docs suggest running from more than one address.

Log the full error object rather than matching on its message text, which can change.

Is it the plan quota or the spend ceiling instead?

Those are different errors, and retrying will not clear them. A plan quota (knowledge bases, storage, scheduled workflows) is checked when you create the thing it counts, and the refusal says which limit you hit and what you have. The monthly language-model spend ceiling refuses new work with an error naming your limit and your spend, until the month rolls over or your plan changes.

Two other refusals look similar but are not rate limits: a query deeper or more complex than the structural limits, and a request body over 10 MB. An oversized request comes back without CORS headers, so a browser reports it as a CORS error. Check the size first.

Related reference docs

• Rate Limiting: every enforced limit, how limits are keyed, and what has no limit today
• Error Handling & Status Codes: which errors are worth retrying and which are not
• API Reference: request limits: query depth and complexity
• Core API Flow: where starting, sending and ending fit in a conversation
• Pricing & Plans: plan quotas and the monthly spend ceiling, which are separate from rate limits

Before you tune your retry logic, read how limits are keyed and check which of your calls appear in the tables.