Server access recovery

For an ordinary standalone application server, rebinding to a personal key updates both the server's managing key and the application's personal binding atomically. A conflict returns 409 APPLICATION_KEY_BINDING_CONFLICT without partial writes. Rebinding to an OAuth key does not create an OAuth link on the application: an existing link must match, and an empty link stays empty. Retrying with the currently selected key repairs an inconsistent personal binding; when nothing needs repair, the response is 400 SAME_KEY.

A server stays bound to its current managing key, so once that key expires or is revoked, another key does not see the server. Access is restored by changing the managing key in your Vibecode account, without recreating the server.

What access loss looks like

Access loss shows up like this:

• GET /v1/infra/servers returns success and an empty data array, although servers exist in the Bitrix24 account.
• GET /v1/infra/servers/:id for a known identifier returns 404 NOT_FOUND.
• At the same time, GET /v1/me confirms the new key is valid: accessMode equals READWRITE and the vibe:infra scope is present.
• In your Vibecode account the server is visible in the Black Hole Servers section and keeps running.

Listing servers with a key that does not manage them:

{
  "success": true,
  "data": []
}

A request to a specific server with the same key:

{
  "success": false,
  "error": {
    "code": "NOT_FOUND",
    "message": "Server not found"
  }
}

The reliable check is to compare your Vibecode account and the API: the server is visible in the Black Hole Servers section but is not returned by GET /v1/infra/servers. Your Vibecode account lists servers by owner, so it is the source of truth on whether the server exists.

The counters in GET /v1/me give an extra hint, but not proof. The infra.limits.used field counts the dedicated virtual machines (STANDALONE) of the current key, and infra.limits.breakdown counts the owner's servers across all their keys in the Bitrix24 account. A zero used with a non-zero breakdown.total does not by itself mean the current key manages nothing: used skips galaxies and Galaxy apps even when the current key is the one managing them. This is a reason to compare with your Vibecode account, nothing more:

{
  "success": true,
  "data": {
    "infra": {
      "limits": {
        "max": 3,
        "used": 0,
        "breakdown": {
          "direct": 7,
          "agents": 0,
          "bots": 0,
          "total": 7
        }
      }
    }
  }
}

The hint has other caveats too. A server that lost its key entirely does not appear in breakdown — both counters stay at zero there, although the server runs and is visible in your Vibecode account. Conversely, breakdown also counts the virtual machines of agents and bots: they also give used: 0 with a non-zero total, but they are managed in their own sections of your Vibecode account rather than through /v1 — see AI agents. For more on galaxies, see Galaxy app. So the counters point to where to look, but the comparison with your Vibecode account is what settles it.

Why the server is not visible

A server has two different bindings. Ownership is tied to a user and is not affected by operations on keys. The apiKeyId field means something else — which key manages the server right now.

The /v1/infra/* endpoints authorize access by the managing key: a request sees only the servers whose apiKeyId matches the calling key. Your Vibecode account relies on ownership, so the server stays visible there. Hence the discrepancy: the server is in your Vibecode account, but the API does not return it for the new key.

Server data is not affected when a key expires. The virtual machine, the deployed application, the settings and the subdomain keep working — only management through the API is unavailable.

How to restore access

The managing key is changed in your Vibecode account by the server owner:

1. Open the Black Hole Servers section.
2. Find the server in the list.
3. In the server card menu, select Change managing key.
4. Select a new key from the list and confirm.

During a move to a galaxy, the prepared place's card is hidden. To change its managing key, click Change the place key on the move banner while the move is waiting, has failed or is ready, select a new key and confirm. Change the old server's key separately through Change managing key in its card menu: the place button does not change the source key. If the agent receives 403 WRONG_KEY, it must stop until the owner aligns the source and place managing keys with the key the agent will use for the move. The agent must then update X-Api-Key, as described below.

Second step: switch the key on the client side too. The rebind hands the server to the key you chose, but it does not change the secret your client or AI agent is already sending. While it keeps sending the old X-Api-Key, the answer stays 403 WRONG_KEY — which reads as if the rebind had not worked. After confirming, take the new key's value from the API Keys section and put it into the X-Api-Key header.

If the server has no managing key, its card shows a Restore access button that opens the same selection. When the card shows Ownership lost, first click Reclaim — this returns the server to your ownership, after which the key selection appears. Only a Bitrix24 account administrator sees ownerless servers and can reclaim them, and the card is not shown to anyone else.

The change affects only the managing binding. The virtual machine, the data, the settings and the subdomain stay untouched, and no restart is performed. After confirmation the new key immediately sees the server in GET /v1/infra/servers — provided its validity period has not ended. The set of available operations depends on the resource type: a dedicated virtual machine (STANDALONE) supports both lifecycle operations and deployment, while a Galaxy app (GALAXY_APP) supports deployment and deletion, because it has no virtual machine of its own and there is nothing to wake or reboot. The server owner receives a message from the companion bot that the managing key has been changed.

What an application key can do without a rebind

A rebind is not always needed. Permissions on a server depend on what you touch:

So it is normal for a deploy and an exec to go through while stopping the server with the same key returns 403 WRONG_KEY. That is not a fault: use the managing key for machine operations, or rebind the server.

Requirements for the new key

The selection list shows only eligible keys. A key is eligible when all conditions are met:

The platform returns the list already filtered, so an expired key never appears in it. Each key's expiration date is shown in the API Keys section; keys with less than a week left are flagged in the list.

If there are no eligible keys, create a new one in the API Keys section with the vibe:infra scope — the form lets you do this without leaving the key change dialog.

When this is needed

These situations all lead to the same visible outcome — the server runs, and the new key does not see it. But there are three states behind it, and the procedure differs.

The managing key is in place but does not work. The server binding is intact — the key itself has become unusable:

1. The key secret is lost. The key is valid, but its value was not saved at creation. A key value is shown once and cannot be recovered.
2. The key is revoked. The key was moved to the REVOKED state — by the owner, for example after a compromise, or by the platform when a self-hosted Bitrix24 portal is disconnected: disconnection revokes the user's keys and does not touch the server binding.
3. The key expired. The validity period has ended, and requests are rejected with the 401 KEY_EXPIRED code.

In all three cases the procedure is the usual one — change the managing key to a new one.

The server is left without a managing key. The apiKeyId field is empty, but the owner is kept. The card shows a Restore access button that opens the same key selection. A key with running servers cannot be deleted manually — the deletion check forbids it.

The server is left without an owner as well. Both fields are empty. This happens after the owner's account is deleted: their keys are deleted along with it, and userId and apiKeyId are nulled at the same time. The card shows Ownership lost — first click Reclaim, and only then does the key selection appear. Only a Bitrix24 account administrator sees such servers.

Reclaiming ownership works for dedicated virtual machines (STANDALONE). A Galaxy app left without an owner cannot be reclaimed — the platform marks it deleted. While the app still has an owner, its managing key is changed the usual way.

Errors

The full code reference is Error codes.

Known specifics

Deleting a key with active servers fails. The request returns 409 KEY_HAS_ACTIVE_SERVERS. Change the managing key of those servers — you do not need to delete the servers themselves. The full number of servers comes in details.activeServerCount when deleting from your Vibecode account and in error.details.activeServerCount for DELETE /v1/keys/:id. The list sits next to the counter — in details.servers and error.details.servers respectively. The list holds at most 10 servers — the newest ones. When the counter is above ten, rely on it and look at the remaining servers in your Vibecode account. If the key also has an agent or a bot, the next attempt returns 409 KEY_HAS_LINKED_AGENT — rebinding the servers does not clear that check.

The key change is available only in your Vibecode account. The operation has no /v1 equivalent: rebinding a running server is a human decision, not one for an automated client. A vibe_api_ key cannot make this call.

Deployment with a key that does not manage the server returns 403 WRONG_KEY. The response comes when the server exists but is managed by another key. The hint field explains the situation and points to changing the managing key as the way to recover.

A server created by an application can be brought back under that application. Move it to a personal API key and then back — the authorization key of a live application accepts the binding when it carries the vibe:infra scope: without that right the key is not eligible and never appears in the picker (the full conditions are in the table above). While the server sits on the personal key, GET /v1/infra/servers/:id with the application key returns 404 NOT_FOUND and POST /v1/infra/servers/:id/deploy returns 403 WRONG_KEY; after the return both calls work with the application key again.

One application — one server. A change to an application key that already owns a live server is refused with 400 APP_KEY_TARGET_HAS_SERVER. This is the same rule under which deleting an application with active servers returns 409 APP_HAS_ACTIVE_SERVERS.

A personal key is linked to at most one application. When the server has its own application, changing to a personal key also moves that application's link to the new key. A key already linked to another application does not appear in the picker, including when that application was deleted and the key was kept. A direct request with such a key returns 409 APPLICATION_KEY_BINDING_CONFLICT with details.reason set to TARGET_SLOT_OCCUPIED. Retrying does not clear this refusal — pick a different key.

The procedure applies to servers and Galaxy apps. The Black Hole Servers section shows dedicated virtual machines (STANDALONE) and Galaxy apps (GALAXY_APP). A galaxy host (GALAXY) lives in the Galaxies section, and there is no managing-key change there — in GET /v1/infra/servers it is returned along with the rest, so an empty response from the new key does not let you tell it apart.

A simultaneous key change from two devices is resolved by the target key. When both requests picked the same key, the second request, started before the first one changed the binding, returns 200 — the binding is already what it asked for. A request sent after the change is an ordinary retry with the already selected key, and the rule from the top of this page applies to it: if there is nothing to restore, the answer is 400 SAME_KEY. When the requests picked different keys, the second one returns 409 CONCURRENT_REBIND: refresh the page and check the current binding.

See also

• Server list
• Infrastructure
• Keys and authorization
• Error codes