Rate limits

Tebar limits requests on two levels:

1. A general per-minute limit on every request made with an API key or OAuth token.
2. Per-feature limits on actions that are costly or easy to abuse, such as syncs and uploads.

Social platforms have their own limits too, such as posts per day. Tebar doesn't set those (see Platform limits).

General limitCopy Anchor Link

The general limit counts every request from the API keys and OAuth tokens of one Tebar account, REST API and MCP together. The dashboard isn't counted.

Limit = 60 requests a minute + 5 for each active social account, at most 600.

It's counted in 1-minute windows. All API keys of the same account share one count, so a new key doesn't raise the limit. Tebar doesn't limit how many posts you make; only your plan's quota and the platforms' rules do.

Headers on every responseCopy Anchor Link

Use RateLimit-Remaining to slow down before you run out, for example when working through a large queue.

When you go over the limitCopy Anchor Link

The API answers 429 Too Many Requests with a Retry-After header (seconds) and this body:

{
  "error": {
    "code": "rate_limited",
    "message": "Too many requests: 65 a minute for this account. Try again in 23 seconds.",
    "details": { "retry_after_seconds": 23, "limit": 65 }
  }
}

Wait for Retry-After, then send the same request again. A request refused with 429 isn't processed at all, so it's safe to resend. For POST /v1/posts, keep the same Idempotency-Key so a post doesn't go out twice if an earlier answer got lost on the way.

async function tebar(path, init = {}, tries = 3) {
  const res = await fetch(`https://api.tebar.app/v1${path}`, {
    ...init,
    headers: { Authorization: `Bearer ${process.env.TEBAR_API_KEY}`, ...init.headers },
  });
  if (res.status === 429 && tries > 1) {
    const wait = Number(res.headers.get('Retry-After') ?? 5);
    await new Promise((r) => setTimeout(r, wait * 1000));
    return tebar(path, init, tries - 1);
  }
  return res;
}

In n8n, turn on Retry On Fail on the HTTP Request node and set Wait Between Tries to at least 5 seconds.

MCPCopy Anchor Link

MCP tools share the same general limit as the REST API. Over the limit, the /mcp endpoint answers HTTP 429 with a Retry-After header and the body { "error": "rate_limited", "error_description": "…" }. Per-feature limits inside a tool show up as that tool's error message, and the AI agent can try again after waiting. One exception: list_comments with refresh: true doesn't fail when its sync limit is used up; it returns the comments already stored without reading the platform again.

Per-feature limitsCopy Anchor Link

These apply on top of the general limit and count per Tebar account unless stated otherwise. Over one, the answer is also 429 rate_limited; details.retry_after_seconds is the longest you may need to wait (the window's length).

There's no need to call syncs over and over: comments, DMs, and insights are kept up to date in the background. To hear about new comments as they arrive, use outgoing webhooks instead of polling.

Platform limitsCopy Anchor Link

Every platform limits posts per account per day and calls to its own API. These limits belong to the social account, Tebar can't raise them, and posts made in the platform's app or other tools count toward them too.

• Check the posting quota left with GET /accounts/{id}/publishing-limit before sending many posts.
• When a platform refuses because of its limit, the post target fails with an error_code such as publish_limit_reached or rate_limited (see Errors). When the reset time is known, the target stays pending and retry_after holds the next attempt.