key_limit

What it means

key_limit is the error code the OneLifeVibe Platform API returns when a key creation request conflicts with the current state of your account rather than with the request itself. The request is well formed; the plan simply has no room for another active key. That is why the status is 409 (Conflict) and not 400 or 422.

The response follows the standard error shape: {"error":{"code":"…","message":"…","hint":"…"}}. The code field carries key_limit, and the message names the plan and its active key allowance, for example: The <plan> plan allows <n> active keys. Codes are stable across releases, so branch on error.code. Never match on the message text, which can change wording or plan names.

Why you are seeing it

You hit this when creating a key in the console and the plan's key count is already fully used. The limits are Sandbox 1, Starter 3, Growth 10 and Scale 25 active keys.

Active means counted against the plan, so a key you created for a test script last month still occupies a slot until it is revoked. Teams commonly run into key_limit after handing out separate keys per environment or per service and then adding one more.

A closely related code is endpoint_limit. If you are tightening your error handling, handle both, but keep them separate: key_limit is about how many keys exist, not about how often they are called.

How to fix it

Pick one of two paths. First, revoke a key you no longer use, which frees a slot immediately, then repeat the creation request. Second, upgrade the plan so its key allowance covers how many keys you actually need.

To help the person doing either, the response includes details.billing_url, which links straight to the Billing tab where the plan change happens. Surface that link rather than describing the plans in your own copy, so the pricing and limits shown are always the current ones.

Audit before you revoke. A key that is still wired into a deployment will start failing the moment it is revoked, and that failure can look unrelated to key management. Check which integrations still use the key first.

Handling it in code

Treat key_limit as a terminal condition for that request. Retrying the same call with the same payload will keep returning 409 until the key count changes, so do not put it in your exponential backoff loop. Parse the body, read error.code, and stop.

A practical branch: if code is key_limit, log the plan and the allowance from the message for your own audit trail, show the operator the hint and details.billing_url, and exit the key-provisioning job with a clear status. Anything else in a 409 handler should be routed separately rather than collapsed into one generic conflict message.

If you provision keys automatically, check the current count before you ask for a new one, and revoke keys as part of the same job that retires an environment. That keeps the count bounded and avoids a queue of provisioning tasks all failing on the same limit.