#Add user or department

POST /v1/infra/servers/:id/access

Adds an access entry to a BLACKHOLE server: a specific Bitrix24 user (with the NAMED_USERS policy) or a department (with the DEPARTMENT policy). The policy is not changed automatically — switch it separately via PATCH /access-policy if you have not done so yet. Duplicates (the same userId or departmentId on the same server) return 409 ALREADY_EXISTS.

#Parameters

#Request fields (body)

#Examples

#curl — personal key

# Add a user
curl -X POST https://vibecode.bitrix24.com/v1/infra/servers/SERVER_ID/access \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type": "user", "userId": "243", "userName": "Kate Smith"}'

# Add a department
curl -X POST https://vibecode.bitrix24.com/v1/infra/servers/SERVER_ID/access \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type": "department", "departmentId": "5", "departmentName": "Development"}'

#curl — OAuth application

curl -X POST https://vibecode.bitrix24.com/v1/infra/servers/SERVER_ID/access \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"type": "user", "userId": "243", "userName": "Kate Smith"}'

#JavaScript — personal key

const res = await fetch(
  `https://vibecode.bitrix24.com/v1/infra/servers/${serverId}/access`,
  {
    method: 'POST',
    headers: {
      'X-Api-Key': 'YOUR_API_KEY',
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      type: 'user',
      userId: '243',
      userName: 'Kate Smith',
    }),
  }
)
if (res.status === 201) {
  const { data } = await res.json()
  console.log(`Added: ${data.userName} (entry ${data.id})`)
}

#JavaScript — OAuth application

await fetch(
  `https://vibecode.bitrix24.com/v1/infra/servers/${serverId}/access`,
  {
    method: 'POST',
    headers: {
      'X-Api-Key': 'YOUR_APP_KEY',
      'Authorization': 'Bearer USER_SESSION_TOKEN',
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      type: 'department',
      departmentId: '5',
      departmentName: 'Development',
    }),
  }
)

#Response fields

#Response example

Adding a user:

{
  "success": true,
  "data": {
    "id": "b3a6f8d1-3c2a-4e17-9f0b-1a7c2d4e5f60",
    "serverId": "e765edfc-ba0a-43de-b8ea-838dd872c522",
    "userId": "243",
    "userName": "Kate Smith",
    "networkUserId": null,
    "grantedBy": "f1d2e3c4-5b6a-4d0e-8f1a-2b3c4d5e6f70",
    "createdAt": "2026-04-22T10:15:00.000Z"
  }
}

Adding a department:

{
  "success": true,
  "data": {
    "id": "c7d8e9f0-1a2b-3c4d-5e6f-7a8b9c0d1e2f",
    "serverId": "e765edfc-ba0a-43de-b8ea-838dd872c522",
    "departmentId": "5",
    "departmentName": "Development",
    "grantedBy": "f1d2e3c4-5b6a-4d0e-8f1a-2b3c4d5e6f70",
    "createdAt": "2026-04-22T11:30:00.000Z"
  }
}

#Error response example

409 — the entry already exists:

{
  "success": false,
  "error": {
    "code": "ALREADY_EXISTS",
    "message": "Access entry already exists"
  }
}

#Errors

The full list of common API errors — Errors.

#Known specifics

• userName and departmentName are for display only. Matching during the access check uses userId/departmentId — the name does not affect authorization. The name is used for display in the list when the Bitrix24 integration is temporarily unavailable.
• networkUserId is filled in asynchronously. Right after the POST, the field is null. In the background, the platform calls the Bitrix24 webhook (if available), finds the user's Network ID, and updates the entry. This is needed for matching when the user signs in to Vibecode via Network OAuth (rather than through your Bitrix24 account).
• Uniqueness — the pair (serverId, userId) for users and (serverId, departmentId) for departments. To "update" an entry, first DELETE, then POST.
• The policy is not changed automatically. If the server is in OWNER_ONLY, adding an entry will not act as "opening access" — first switch the policy to NAMED_USERS (or DEPARTMENT) via PATCH /access-policy.

#See also

• Access list — verify that the entry was added.
• Delete entry — DELETE /v1/infra/servers/:id/access/:accessId.
• Access policy — switch NAMED_USERS / DEPARTMENT.
• Search Bitrix24 users — find the userId before adding.

#Delete access entry

DELETE /v1/infra/servers/:id/access/:accessId

Deletes an access entry — a user or a department — from a BLACKHOLE server's list. The endpoint is universal: the same accessId may refer to either a user (BlackHoleAccess) or a department (BlackHoleDepartment) — the platform first looks in the first table, then in the second. After deletion, the entry disappears from GET /access.

#Parameters

#Examples

#curl — personal key

curl -X DELETE -H "X-Api-Key: YOUR_API_KEY" \
  https://vibecode.bitrix24.com/v1/infra/servers/SERVER_ID/access/b3a6f8d1-3c2a-4e17-9f0b-1a7c2d4e5f60

#curl — OAuth application

curl -X DELETE -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  https://vibecode.bitrix24.com/v1/infra/servers/SERVER_ID/access/ACCESS_ID

#JavaScript — personal key

const res = await fetch(
  `https://vibecode.bitrix24.com/v1/infra/servers/${serverId}/access/${accessId}`,
  {
    method: 'DELETE',
    headers: { 'X-Api-Key': 'YOUR_API_KEY' },
  }
)
const { success } = await res.json()
if (success) console.log('Entry deleted')

#JavaScript — OAuth application

await fetch(
  `https://vibecode.bitrix24.com/v1/infra/servers/${serverId}/access/${accessId}`,
  {
    method: 'DELETE',
    headers: {
      'X-Api-Key': 'YOUR_APP_KEY',
      'Authorization': 'Bearer USER_SESSION_TOKEN',
    },
  }
)

#Response fields

#Response example

{ "success": true }

#Error response example

404 — entry not found (already deleted, wrong accessId, or accessId of another server):

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

#Errors

The full list of common API errors — Errors.

#Known specifics

• Physical deletion, not soft-delete. The entry is erased from the database. It cannot be restored — you will have to call POST /access again.
• accessId is bound to the server. An attempt to delete an access entry of another server (correct accessId but wrong :id in the path) returns 404 NOT_FOUND. The platform deliberately does not reveal the existence of other servers' entries.
• Deletion does not change the policy. If you delete all users while accessPolicy: "NAMED_USERS", the policy stays NAMED_USERS (and the application becomes inaccessible to everyone except the key owner). To "fully restore privacy", switch the policy back to OWNER_ONLY via PATCH /access-policy.
• The key owner cannot be deleted. The owner always has access, even if they are not in the list. To revoke your own access, you need a different API key.

#See also

• Access list — get the accessId to delete.
• Add user/department — POST /v1/infra/servers/:id/access.
• Access policy — PATCH /v1/infra/servers/:id/access-policy.