On this page
Guides / Limits and quotas

Limits and quotas

Per-key rate limits, rate limit headers, monthly quota, and how the SDKs retry on their own.

Updated View .md

The Meteor API applies two kinds of limit per API key: a rate limit (how many requests per minute) and a quota (how many requests per month). Both protect the platform and both are visible in every response — you never have to guess how much you have left.

Rate limit (requests per minute)

Each key has its own budget of requests per minute, independent of the rest of your workspace's traffic. The default is 300 requests per minute; your plan may assign the key a higher limit when you issue it.

The limit is counted per key — not per IP, not per workspace — so two keys in the same workspace never compete with each other.

Headers on every response

Every public API response carries the state of your rate limit, so you can pace yourself without hitting the wall:

HeaderWhat it says
X-RateLimit-LimitThe request ceiling for the current window (reflects your key's limit).
X-RateLimit-RemainingHow many requests you have left in the window.
X-RateLimit-ResetSeconds until the window resets.
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 the 429 by hand. If you integrate the API directly, wait the seconds Retry-After indicates before retrying.

Monthly quota

On top of the per-minute rate limit, your plan defines a monthly quota of requests. Once you pass it, the API answers 429 with code: "quota_exceeded". The quota depends on your plan; 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.

Quotas and rate limits depend on the workspace's active plan. They are resolved when the key is used—even if you created it before subscribing—and are reflected in X-RateLimit-Limit.

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 rate limit and the monthly quota. 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

← PreviousErrors, idempotency and pagination