This page collects every fixed limit of K-Block Cloud and the Gateway in one place: rate limits, request sizes, time bounds such as the approval lifetime, webhook retries, page sizes, key rules and plan quotas. It ends with the runtimes and versions K-Block supports.
The values are the ones K-Block enforces in this version. Where you choose a value yourself, for example the approval lifetime in your organization's settings, the row gives the range you can choose from.
Cloud API rate limits
Two limits apply to every Cloud API route under /api/v1:
| Limit | Value |
|---|---|
| Per client IP address | 1,200 requests per minute |
| Per credential (session or management API key), when the request carries one | 600 requests per minute |
A client IP here is one IPv4 address or one IPv6 /64 network.
Sensitive routes have their own limits on top:
| Route | Limit |
|---|---|
POST /auth/signin | 30 per 15 minutes per client IP; 10 per 15 minutes per e-mail address and client IP; 50 per 15 minutes per e-mail address (not counted for a browser that signed in to that address before, under its current password); 150 per 15 minutes per IPv6 /48 (IPv6 clients only) |
POST /auth/signup | 10 per hour per client IP; 5 per hour per e-mail address; 50 per hour per IPv6 /48 (IPv6 clients only) |
POST /auth/password | 10 per 15 minutes per user |
POST /auth/email/resend | 1 per minute per e-mail address; 20 per hour per client IP; 5 per hour per e-mail address |
POST /auth/email/verify | 60 per 15 minutes per client IP |
POST /auth/email/change/approve and …/reject | 60 per 15 minutes per client IP, shared |
POST /me/email | 10 per hour per user |
POST /auth/password-reset | 20 per hour per client IP; 5 per hour per e-mail address and client IP |
POST /auth/password-reset/confirm | 30 per 15 minutes per client IP |
POST /orgs/<org-id>/invitations | 20 per hour per inviting user; 50 per hour per organization |
POST /invitations/accept | 20 per 15 minutes per user |
POST …/webhooks/<id>/test and …/deliveries/<id>/redeliver | 5 per minute per endpoint, shared |
POST …/agents/<id>/dry-run | 60 per minute per credential; 600 per minute per organization |
| Simulations, shadow reports, decision maps, diffs and observe window reports | 10 per minute per organization; callers who can only read (viewers, approvers, management keys without a write scope) get at most 5 of them |
POST …/mcp-servers/<id>/discover and tool creation that discovers | 2 at a time per organization; 8 at a time for all organizations together (429 DISCOVERY_BUSY) |
A refused request answers 429 RATE_LIMITED (DISCOVERY_BUSY for discovery) with Retry-After and details.retry_after_seconds. Nothing was changed.
The two general limits and the dry-run, report and discovery limits can let more requests through than these numbers. Do not rely on that: design your scripts for the numbers above.
E-mail per recipient
Independently of who asks, each recipient address receives at most:
- 10 account e-mails per hour across verification, e-mail change and notices;
- 5 password reset e-mails per hour, a budget of their own;
- 10 security notices per hour (password changed, password reset), a budget of their own.
Requests over these budgets still get their normal answer, but nothing more is sent. This keeps the answers from revealing whether an address has an account.
Gateway rate limits
| Limit | Value |
|---|---|
| Requests per gateway API key | Bursts of 120, refilled at 20 per second. Each extra message of a JSON-RPC batch costs one more. |
| Concurrent approval waits | 20 per gateway API key and 1,000 for all keys together |
| Calls of one organization in progress at once | Bounded per Gateway, fairly between organizations: further calls queue per organization, at most 1,000 waiting, each at most 30 seconds, then refused unavailable / GATEWAY_BUSY (retryable; nothing recorded). A call waiting for an approval or for the upstream server does not count. This keeps one organization's burst from slowing down the others; it is not a throughput guarantee, and it cannot be changed per organization. |
Over the request limit the Gateway answers HTTP 429 with Retry-After. Over the wait limit, a call that would wait for an approval returns at once as pending instead of waiting; the agent can resume it later. These limits can let more requests through than the numbers here; design your agents for the numbers above.
Request and response sizes
| Limit | Value |
|---|---|
| Cloud API request body | 1 MiB (413 PAYLOAD_TOO_LARGE) |
Gateway /mcp request body | 1 MiB (HTTP 413) |
| Response of an upstream MCP server to the Gateway | 1 MiB |
| Arguments of one tool call | At most 224 KiB as canonical JSON, and at most 512 KiB as a receipt prints them (indented, one member or array element per line); nested at most 28 levels deep (the arguments object itself is level 1). Numbers must be whole numbers between −(2^53 − 1) and 2^53 − 1: send decimals such as prices, quantities and sensor readings as strings. No U+0000 in any text, and no two member names in one object that differ only by letter case. A call over one of these limits is refused invalid_request / INVALID_ARGUMENTS, and nothing is recorded. |
| Policy document | 256 KiB |
| Argument conditions | At most 16 per rule and 512 per document. A path has at most 28 tokens and 4 * tokens; in and not_in take at most 256 values, starts_with and ends_with at most 64; text operands up to 1,024 characters; decimal bounds and values up to 40 digits before and after the point. See Argument conditions. |
| Policy versions per organization | 5,000 versions and 64 MiB of stored documents, all policies together (409 POLICY_VERSION_LIMIT). Versions are never deleted. |
| Lint warnings returned by policy validation | 100 |
| Webhook receiver response | Keep the body small: an answer whose Content-Length exceeds 64 KiB counts as a failed attempt, even with a 2xx status. A longer body without a declared length is read only up to 64 KiB. |
| Tool discovery from an MCP server | At most 20 tools/list pages and 2,000 tools are read; more than 8 MiB of answers in total is refused (DISCOVERY_TOO_LARGE). |
| Names of accounts, organizations, API keys, agents, MCP servers and policies | 1 to 200 characters, one line, no control characters |
| Webhook description | Up to 500 characters |
Time bounds
| Bound | Value |
|---|---|
Approval lifetime (organization setting approval_ttl_seconds; a require_approval rule can set its own approval_ttl_seconds, which then wins) | 60 seconds to 30 days (2,592,000 seconds). Default 24 hours. An approval request also never outlives the agent's delegation. |
Approval wait per call (kblock/wait-seconds) | 0 to 60 seconds. A larger request is lowered to 60 seconds. |
| Upstream MCP call timeout | 30 seconds for the whole exchange with your MCP server. |
Observe window length (organization setting observe_max_hours) | 0 to 168 hours (7 days). Default 0, which means observe is off. A window cannot be longer than the setting. |
| Session | Ends after 12 hours without activity, 7 days after sign-in at the latest. |
| Invitation | 1 hour to 30 days. Default 7 days. |
| Webhook secret after rotation | The replaced secret keeps signing deliveries, together with the new one, for 24 hours. |
| Overview period | 1 to 365 days. |
| Policy evidence export period | Up to 400 days. |
Webhook delivery
| Limit | Value |
|---|---|
| Attempts per delivery | 8; then the delivery is failed |
| Delay between attempts | 30 seconds after the first failure, doubling each time, at most 6 hours |
| Timeout per attempt | 10 seconds; redirects are not followed; only a 2xx answer counts as delivered |
| Deliveries in flight | 1 per endpoint and 4 per organization at a time |
A failed delivery can be sent again on request (redeliver), which starts its 8 attempts again; only a failed delivery of an enabled endpoint can be redelivered. See Webhook delivery.
Lists and pages
| Limit | Value |
|---|---|
Page size of list routes (?limit=) | 1 to 100; default 50 |
| Observe windows shown per agent | The 20 most recent |
Keys, identities and delegations
| Limit | Value |
|---|---|
| Gateway API key | Bound to exactly one agent; no scopes. |
| Management API key scopes | At least one of read, agents:write, tools:write, policies:write, approvals:read, receipts:read; no duplicates. |
| API key expiry | Optional. When set, it must be in the future; there is no upper bound. |
| API keys per organization | By plan (below). Expired keys still count until they are revoked. |
| Personal K-Block identities bound per person | 5 at a time |
| Active delegations per agent | 100 |
| Approvers of one approval request | Up to 32 identities. Each member counts with at most their 5 newest identities. More than 32 admitted members denies the call (TOO_MANY_APPROVERS). |
| Password length | 12 to 256 characters |
Plan quotas
Each organization has a plan. Without a verified subscription it is on the free Developer plan. unlimited means no limit.
| Limit | Developer (free) | Startup | Growth | Scale | Enterprise |
|---|---|---|---|---|---|
| Protected actions per month | 500 | 25,000 | 250,000 | 2,000,000 | unlimited |
| Members | 1 | 10 | 50 | 200 | unlimited |
| API keys (not revoked) | 5 | 25 | 100 | 500 | unlimited |
| Webhook endpoints | 2 | 10 | 50 | 200 | unlimited |
| Agents | 50 | 250 | 1,000 | 5,000 | unlimited |
| MCP servers | 50 | 250 | 1,000 | 5,000 | unlimited |
| Tools | 500 | 2,500 | 10,000 | 50,000 | unlimited |
| Policies | 50 | 250 | 1,000 | 5,000 | unlimited |
| Operational data retention | 30 days | 90 days | 365 days | 730 days | unlimited |
Developer is for one user. Team membership starts with Startup. Developer has room for one member, the owner, so inviting someone to a Developer organization, or accepting an invitation to it, is refused with 402 PLAN_LIMIT_EXCEEDED.
Over a quota, the request answers 402 PLAN_LIMIT_EXCEEDED, and a protected call over the monthly limit is refused by the Gateway. Pending invitations count against the member limit. Protected actions are counted per calendar month in UTC. Reaching a limit, or moving to a smaller plan, never deletes or disables what the organization already has: only new items are refused.
After the retention period, the operational data of finished actions (call arguments kept beside the decision, error details, tool results) and old webhook events are removed; receipts, signed evidence and the audit log are kept. See Data retention. Prices are not part of the plans: they are set in Creem, K-Block's billing provider. See Billing.
Supported versions
| Component | Version |
|---|---|
Node.js for @kblockai/client@0.1.0-rc.1 and @kblockai/sdk@0.1.0-rc.1 | 22 or newer |
Python for kblock==0.1.0rc1 | 3.10 or newer; the package declares 3.10, 3.11, 3.12 and 3.13. K-Block's recorded test run used Python 3.13; Python 3.10 and 3.11 were not tested. |
The public packages are pre-release in this version. See TypeScript client and Python for the install lines.
Browsers
There is no official browser support list in this version. The dashboard keeps people's K-Block keys in the browser, so it needs:
- WebCrypto, which browsers offer only in a secure context: open the dashboard over HTTPS. Without it, key operations fail with
CRYPTO_UNAVAILABLE. - IndexedDB, where the keys are stored. Without it, key operations fail with
STORAGE_UNAVAILABLE.
Keys last only as long as the browser keeps the site's data: private windows discard them when closed, and a browser may delete them when it runs low on storage or, in some browsers, after a period without visits. See How the browser stores keys.
K-Block's automated browser tests run in Microsoft Edge, a Chromium-based browser. Other browsers are not tested.
What to do next
- Install a client on a supported runtime: TypeScript client or Python.
- See how errors over a limit look: Error codes.
- Change your plan: Billing.