Limits and quotas

Daily request limit per workspace, per-key rate limit, headers, the monthly quota of the Developer and Tech Partner plans, and what to do with each 429.

The Meteor API applies two limits to all traffic that arrives with an API key:

• a daily limit per workspace: how many requests your workspace can make in a day, adding up all of its keys;
• a rate limit per key: how many requests per minute each key can make.

Both are visible in every response, so you never have to guess how much you have left. On top of that, the Developer and Tech Partner plans have a monthly quota per key, met_test_ keys have a daily cap on test runs, and any key can carry an Energy budget.

Daily request limit per workspace

Every plan includes a number of requests per day for the whole workspace. All of the workspace's keys add up, so creating another key does not give you more room.

What counts: every request authenticated with an API key, whether it comes through the API, the SDK, the CLI or the MCP server. On MCP, each POST /mcp counts as one request, even if it calls several tools inside. What you do from the Meteor dashboard with your session does not count.

What a day is: the UTC day. The counter goes back to zero at 00:00 UTC, which is 7:00 p.m. in Colombia.

Daily limit headers

Every response to a request made with an API key carries the state of the day:

curl -i https://api.met.meteor.com.co/api/v1/contacts \
  -H "Authorization: Bearer met_live_your_key"
# ...
# HTTP/2 200
# x-daily-limit: 10000
# x-daily-remaining: 3120
# x-daily-reset: 18230

The count is refreshed every minute, so X-Daily-Remaining can run a few seconds behind your actual traffic.

What happens when you reach the limit

• At 100% your workspace gets a notice, once a day, and the API keeps answering. Going over the limit does not cut off your integration.
• At three times the limit (3×), the API answers 429 with code: "daily_request_limit_exceeded" and a Retry-After with the seconds left until 00:00 UTC. From then on, every request made with a key of that workspace gets the same 429 until the reset.

{
  "error": {
    "type": "rate_limit_error",
    "code": "daily_request_limit_exceeded",
    "message": "Tu workspace superó el límite diario de peticiones."
  }
}

Decide by code, not by the text of message. Unlike rate_limited, this 429 is not solved by retrying in a few seconds: the Retry-After can be hours. Since @meteor.ia/sdk 0.9.0 and meteor-ia 0.3.0, the official SDKs don't retry it: they hand you the error right away, with retryAfter (retry_after in Python) and isQuota (is_quota) set to true; if your integration runs batch jobs, watch X-Daily-Remaining and slow down before you get there.

How to raise it

If you are running short, you have two ways out:

• The "API requests" add-on, without changing plans: +1,000 requests a day for US$15 a month or +10,000 a day for US$90 a month. You buy it under Billing → Add-ons; it stacks on top of what your plan includes and shows up in X-Daily-Limit.
• Moving up a plan, if you are also running short on contacts, tasks or members.

How to check it

GET /billing/limits returns every limit of your plan along with what you have used, and it needs the billing:read scope. The daily request limit is the api_requests_daily resource:

{
  "object": "plan_limits",
  "plan": { "slug": "oficina", "name": "Oficina", "price_monthly_usd": 299 },
  "resources": [
    {
      "key": "api_requests_daily",
      "label": "Peticiones de API",
      "period": "day",
      "used": 6880,
      "included": 10000,
      "extra": 0,
      "limit": 10000,
      "unlimited": false,
      "enforcement": "soft",
      "resets_at": "2026-09-26T00:00:00Z",
      "addons": [
        { "slug": "api_daily_1000", "grants": 1000, "price_usd": 15, "owned_quantity": 0 },
        { "slug": "api_daily_10000", "grants": 10000, "price_usd": 90, "owned_quantity": 0 }
      ]
    }
  ]
}

limit is included plus extra (what your add-ons add). enforcement says how each resource is applied: hard blocks when you reach it, soft warns at 100% and stops you at three times, and none never stops you. A resource with no cap comes with unlimited: true and limit: null. The same response carries the plan's other resources (members, contacts, tasks a day, WhatsApp numbers and Meta accounts), each with its add-ons.

Rate limit per key (requests per minute)

Each key has its own budget of requests per minute, separate from the rest of your workspace's traffic. The default is 300 requests per minute.

Your plan does not raise that number: it can only set a lower one. Today the Developer and Tech Partner plans do, leaving each key at 60 per minute. The other plans use the default. If a key also has a limit of its own, the lower of the two applies.

The limit is counted per key — not per IP, not per workspace — so two keys in the same workspace never compete for pace. The daily limit, on the other hand, is one for all of them.

Rate limit headers

curl -i https://api.met.meteor.com.co/api/v1/runs \
  -H "Authorization: Bearer met_live_your_key"
# ...
# HTTP/2 200
# x-ratelimit-limit: 300
# x-ratelimit-remaining: 99
# x-ratelimit-reset: 60

When you go over: 429 + Retry-After

If you exceed the rate limit, the API answers 429 with a Retry-After header (seconds to wait) and the standard error body:

{
  "error": {
    "type": "rate_limit_error",
    "code": "rate_limited",
    "message": "Too many requests."
  }
}

The official SDKs retry on their own, honoring Retry-After with backoff, so in most cases you don't have to handle this 429 by hand. If you integrate the API directly, wait the seconds Retry-After indicates before retrying.

Limits are resolved against the workspace's active plan every time you use the key, even if you created it before subscribing.

Monthly quota (Developer and Tech Partner plans)

The Developer and Tech Partner plans also have a monthly quota per key: each key keeps its own counter for the month. Once you pass it, the API answers 429 with code: "quota_exceeded" until the next month starts. The other plans have no monthly quota; their ceiling is the workspace's daily limit.

This month's usage and the alerts (80% / 100%) are in the Workbench, under Settings → Developers → Activity → Health — the same place that shows daily volume, p95 latency and every request searchable by request_id.

Daily cap on test runs

Runs you execute with a met_test_ key debit no Energy, which is why they have a cap of their own: a maximum number of test runs per day per workspace, counted separately from the other limits. Once you hit it, POST /runs answers 429 with code: "test_run_daily_cap" and the run does not execute — the cap is checked before the orchestrator is touched, so nothing runs halfway.

{
  "error": {
    "type": "rate_limit_error",
    "code": "test_run_daily_cap",
    "message": "Se alcanzó el límite diario de runs de test de este workspace. Usa una key live o reinténtalo mañana."
  }
}

Unlike rate_limited, this 429 is not solved by retrying: the counter resets the next day. Your plan can raise the cap, and it can also set it to zero (no test runs at all). If you hit it daily while developing, the way out is a met_live_ key — which does debit Energy — or a plan with more room.

Per-key Energy budget

On top of the request limits, each key can carry a spending cap in dollars that you assign under Settings → Developers, at creation time or later, without rotating it. With the automatic cut-off on, once you reach 100% new requests are rejected with 429 and code: "budget_exceeded" until next month or until you raise the cap; without it, the key keeps operating and only warns you. Either way, each threshold crossed (50 / 80 / 100%) arrives as a billing.threshold event if you have a webhook subscribed with billing:read.

It is the limit most worth setting on a key you hand to an agent: it bounds the spend even when the agent loops on a mistake.

In short

• Watch X-Daily-Remaining so you don't run out for the day, and X-RateLimit-Remaining so you don't run out for the minute.
• A 429 with rate_limited is transient → retry after Retry-After (the SDKs do it for you).
• A 429 with daily_request_limit_exceeded is the workspace's daily limit, passed three times over → wait for 00:00 UTC, add the "API requests" add-on or move up a plan.
• A 429 with quota_exceeded is the key's monthly quota (Developer and Tech Partner) → wait for next month or move to a paid plan.
• A 429 with test_run_daily_cap is the daily cap on test runs → wait for the next day or move to a met_live_ key.
• A 429 with budget_exceeded is the key's budget → raise it or wait for next month.