#Добавить пользователя или отдел

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

Добавляет запись доступа к BLACKHOLE-серверу: конкретного пользователя Битрикс24 (при политике NAMED_USERS) или отдел (при политике DEPARTMENT). Политика при этом не меняется автоматически — смените её через `PATCH /access-policy` отдельно, если ещё не переключали. Дубликаты (тот же userId или departmentId на том же сервере) возвращают 409 ALREADY_EXISTS.

#Параметры

#Поля запроса (body)

#Примеры

#curl — личный ключ

# Добавить пользователя
curl -X POST https://vibecode.bitrix24.tech/v1/infra/servers/SERVER_ID/access \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type": "user", "userId": "243", "userName": "Катя Иванова"}'

# Добавить отдел
curl -X POST https://vibecode.bitrix24.tech/v1/infra/servers/SERVER_ID/access \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type": "department", "departmentId": "5", "departmentName": "Разработка"}'

#curl — OAuth-приложение

curl -X POST https://vibecode.bitrix24.tech/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": "Катя Иванова"}'

#JavaScript — личный ключ

const res = await fetch(
  `https://vibecode.bitrix24.tech/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: 'Катя Иванова',
    }),
  }
)
if (res.status === 201) {
  const { data } = await res.json()
  console.log(`Добавлен: ${data.userName} (запись ${data.id})`)
}

#JavaScript — OAuth-приложение

await fetch(
  `https://vibecode.bitrix24.tech/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: 'Разработка',
    }),
  }
)

#Поля ответа

#Пример ответа

Добавление пользователя:

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

Добавление отдела:

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

#Пример ответа при ошибке

409 — запись уже существует:

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

#Ошибки

Полный список общих ошибок API — Ошибки.

#Известные особенности

• userName и departmentName — только для отображения. Для сопоставления при проверке доступа используются userId/departmentId — имя на авторизацию не влияет. Имя используется для отображения в списке, когда интеграция с Битрикс24 временно недоступна.
• networkUserId заполняется асинхронно. Сразу после POST поле null. В фоне платформа вызывает веб-хук Битрикс24 (если доступен), находит Network ID пользователя и обновляет запись. Это нужно для сопоставления, когда пользователь входит в Вайбкод через Network OAuth (а не через ваш портал).
• Уникальность — пара (serverId, userId) для пользователей и (serverId, departmentId) для отделов. Чтобы «обновить» запись — сначала DELETE, потом POST.
• Политика не меняется автоматически. Если сервер в OWNER_ONLY, добавление записи не сработает как «открытие доступа» — сначала переключите политику на NAMED_USERS (или DEPARTMENT) через `PATCH /access-policy`.

#Смотрите также

• Список доступа — проверить, что запись добавилась.
• Удалить запись — DELETE /v1/infra/servers/:id/access/:accessId.
• Политика доступа — переключить NAMED_USERS / DEPARTMENT.
• Поиск пользователей Битрикс24 — найти userId до добавления.

#Удалить запись доступа

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

Удаляет запись доступа — пользователя или отдел — из списка BLACKHOLE-сервера. Эндпоинт универсальный: один и тот же accessId может относиться либо к пользователю (BlackHoleAccess), либо к отделу (BlackHoleDepartment) — платформа сначала ищет в первой таблице, потом во второй. После удаления запись исчезает из `GET /access`.

#Параметры

#Примеры

#curl — личный ключ

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

#curl — OAuth-приложение

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

#JavaScript — личный ключ

const res = await fetch(
  `https://vibecode.bitrix24.tech/v1/infra/servers/${serverId}/access/${accessId}`,
  {
    method: 'DELETE',
    headers: { 'X-Api-Key': 'YOUR_API_KEY' },
  }
)
const { success } = await res.json()
if (success) console.log('Запись удалена')

#JavaScript — OAuth-приложение

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

#Поля ответа

#Пример ответа

{ "success": true }

#Пример ответа при ошибке

404 — запись не найдена (уже удалена, неверный accessId, либо accessId другого сервера):

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

#Ошибки

Полный список общих ошибок API — Ошибки.

#Известные особенности

• Физическое удаление, не пометка на удаление. Запись стирается из базы. Восстановить нельзя — придётся повторно вызывать `POST /access`.
• accessId привязан к серверу. Попытка удалить запись доступа другого сервера (правильный accessId, но неверный :id в пути) вернёт 404 NOT_FOUND. Платформа намеренно не раскрывает факт существования записей чужих серверов.
• Удаление не меняет политику. Если вы удалите всех пользователей при accessPolicy: "NAMED_USERS", политика останется NAMED_USERS (и приложение станет недоступно никому, кроме владельца ключа). Чтобы «полностью вернуть приватность» — меняйте политику обратно на OWNER_ONLY через `PATCH /access-policy`.
• Владельца ключа удалить нельзя. Владелец всегда имеет доступ, даже если его нет в списке. Чтобы забрать у себя доступ — нужен другой API-ключ.

#Смотрите также

• Список доступа — получить accessId для удаления.
• Добавить пользователя/отдел — POST /v1/infra/servers/:id/access.
• Политика доступа — PATCH /v1/infra/servers/:id/access-policy.