REST API
API для интеграций — скрипты, вебхуки, сторонние сервисы. Доступен на тарифе Pro: и выдача ключа, и каждый запрос по нему проверяют активную подписку — истёкший Pro останавливает уже выпущенные ключи, а не только создание новых. Ключи создаются в Настройках → API-ключи. Важное архитектурное ограничение: API отдаёт только метаданные (списки, названия хранилищ, даты, историю действий) — расшифрованное содержимое записей через API недоступно ни при каком scope, потому что API-ключ не имеет и не может иметь доступа к ключу шифрования хранилища (VaultKey). Это то же zero-knowledge устройство, что защищает пароли от самого сервера Сэйфком.
Аутентификация
Каждый запрос требует заголовок Authorization: Bearer sk_live_… с ключом,
созданным в настройках. Ключ показывается один раз, в момент создания — сохраните его сразу, восстановить
позже нельзя, только отозвать и выпустить новый.
curl https://safekom.ru/vault/api/v1/spaces \
-H "Authorization: Bearer sk_live_ваш_ключ"Владелец ключа: личный или организация
Ключ либо личный (видит то же, что видите вы как пользователь: свои пространства и всё, куда вас пригласили), либо принадлежит организации (создать такой ключ может только владелец или администратор организации; ключ жёстко привязан к одной организации и не может обращаться к данным другой, даже если создатель ключа состоит в обеих).
Область доступа (scope)
read | Списки хранилищ, записей (метаданные), история действий организации. |
write | Всё из read, плюс перенос записи в папку, изменение статуса «избранное», перемещение в корзину. Не включает создание записи или изменение пароля — это всегда требует ключа шифрования хранилища, которого у API-ключа нет. |
Лимит запросов
300 запросов за 5 минут на один ключ. При превышении — 429 Too Many Requests. Лимит
отдельный для каждого ключа, не общий на аккаунт.
Эндпоинты
GET /api/v1/spaces
Личные пространства пользователя, от имени которого действует ключ.
GET /api/v1/spaces/{id}/vaults
Хранилища внутри пространства: id, название, иконка, даты создания/изменения.
GET /api/v1/workspaces/{id}/vaults
Хранилища организации. Для ключа, привязанного к организации, доступна только та организация, для которой он выпущен.
GET /api/v1/vaults/{id}/entries?folder_id=&limit=&offset=
Метаданные записей: id, папка, дата создания/изменения, «избранное». Без названия записи
— название, как и остальное содержимое, зашифровано на стороне клиента и недоступно серверу, а значит и
API. limit — 1–500 (по умолчанию 200), offset — для постраничной выборки.
PATCH /api/v1/entries/{id}
Требует scope write. Тело: {"folder_id": 123} и/или
{"is_favorited": true}. Любое поле, относящееся к содержимому записи
(entry_data_encrypted, encryption_nonce, encryption_tag,
encryption_version) отклоняется с 422 — эндпоинт осознанно не позволяет менять
содержимое, даже если бы вызывающий каким-то образом получил зашифрованное значение из другого места.
DELETE /api/v1/entries/{id}
Требует scope write. Перемещает запись в корзину (soft delete) — как обычное удаление в
интерфейсе, запись можно восстановить в течение срока хранения корзины.
GET /api/v1/workspaces/{id}/audit-log?limit=
История действий организации. Требует, чтобы пользователь, от имени которого действует ключ, был
владельцем, администратором или менеджером организации — то же правило, что действует для интерфейса.
limit — до 100 записей за запрос.
Коды ошибок
401 | Ключ отсутствует, неверного формата, отозван или не найден. |
403 | Ключ не подходит по scope (нужен write) или не привязан к запрашиваемой организации. |
404 | Объект не найден или недоступен для пользователя, от имени которого действует ключ — те же правила ролей, что в веб-интерфейсе. |
422 | Некорректное тело запроса — например, попытка отправить зашифрованное содержимое через PATCH. |
429 | Превышен лимит запросов для этого ключа. |
Почему нет создания и чтения содержимого записей
Сэйфком — zero-knowledge менеджер паролей: расшифровка происходит только в браузере, ключом, который никогда не покидает устройство пользователя в открытом виде. API-ключ создаётся на сервере и в принципе не может нести этот ключ шифрования — выдать его через API означало бы либо ослабить всю модель безопасности (хранить ключ шифрования на сервере), либо переложить шифрование на вызывающую сторону API без соответствующей инфраструктуры. Пока это не реализовано, API остаётся метаданными: интеграции вида «сколько записей», «когда последний раз менялось», «кто что делал» — без доступа к самим паролям.