Создание проекта и регистрация первого владельца

В Gigma нет отдельного API-метода «зарегистрировать владельца». Первый владелец создаётся внутри публичного запроса POST /api/projects одновременно с новым проектом.

Сам запрос возвращает только созданный проект. Учётная запись владельца и User Bearer в ответ не входят: для первого входа нужно отдельно запросить одноразовый пароль, выполнить POST /api/login и проверить пользователя через GET /api/user.

Маршруты, схемы запросов, авторизация и опубликованные HTTP-ответы сверены с OpenAPI-контрактом работающего API. Данные, которые сервер создаёт вместе с проектом, и поля UserResource сверены с кодом ProjectController, UserService и UserResource.

Текущий api.json подтверждает Bearer-защиту и ответы GET /api/user, но схема UserResource в нём неполная. Поэтому поля проверки владельца в шаге 4 взяты из кода UserResource, который формирует фактический ответ API.

Результат

После завершения сценария у вас будут:

• идентификатор нового проекта из item.id;
• первая учётная запись User с ролью owner;
• User Bearer владельца;
• подтверждённый доступ к GET /api/user;
• пустой проект, готовый к дальнейшей настройке.

Сохраните item.id из первого ответа. Методы входа и GET /api/user не возвращают идентификатор проекта.

Как устроена регистрация

Сервер выполняет действия в таком порядке:

1. Проверяет name, login и menu_id.
2. Создаёт Project.
3. Добавляет стандартные роли и отделы проекта.
4. Создаёт пользователя с переданным email и ролью owner.
5. Привязывает владельцу пункты выбранного меню, пользовательские интеграции и доступные права.
6. Отправляет приветственное письмо.
7. Возвращает проект через DictionaryResource.

Приветственное письмо не содержит User Bearer и не заменяет запрос одноразового пароля.

Новый проект создаётся без бизнеса, Application, каталога, складов, витрин, домена и демо-данных.

Перед началом

Подготовьте:

• название проекта;
• новый email владельца;
• существующий menu_id для административного меню.

Email проверяется на уникальность во всей таблице пользователей, а не только внутри одного проекта. Один и тот же login нельзя повторно использовать для создания владельца другого проекта.

Публичного метода для получения списка административных меню до регистрации нет. Значение menu_id должно быть известно заранее. Не подбирайте идентификатор и не копируйте его из примера.

Число 0 и строка "0" преобразуются сервером в null до валидации. Поэтому menu_id: 0 завершится ответом 422.

{
    "name": "Acme",
    "login": "owner@example.com",
    "menu_id": 42
}

{
    "item": {
        "id": "314",
        "name": "Acme",
        "avatar": "https://api.gigma.ru/storage/uploads/default.svg",
        "created_at": "2026-08-24T10:00:00.000000Z"
    }
}

{
    "message": "<описание ошибки>",
    "errors": {
        "login": ["<причина>"]
    }
}

Получили 200 — сохраните item.id и переходите к входу владельца.

Шаг 2. Запросите одноразовый пароль

Приветственное письмо, которое отправляется при создании проекта, не является одноразовым паролем. Запросите пароль отдельным методом:

POST /api/send_password HTTP/1.1
Host: api.gigma.ru
Accept: application/json
Content-Type: application/json

{
    "login": "owner@example.com"
}

При успешном действии API возвращает 200:

{
    "message": "Password successfully send"
}

Пароль действует 5 минут. Полный контракт и ошибки описаны в методе «Отправьте пароль на email».

Шаг 3. Получите User Bearer

Передайте email владельца, пароль из письма и название административного клиента:

POST /api/login HTTP/1.1
Host: api.gigma.ru
Accept: application/json
Content-Type: application/json

{
    "login": "owner@example.com",
    "password": "<password_from_email>",
    "device": "owner-console"
}

При успешном входе сохраните user.access_token.value целиком, включая часть до символа |:

Authorization: Bearer <user.access_token.value>

User Bearer нельзя передавать в публичную клиентскую часть сайта или приложения. Храните его в доверенном административном клиенте или на сервере продукта. Не добавляйте токен в URL, аналитику и обычные логи.

Полный ответ и ошибки описаны в методе «Получите Bearer сотрудника».

Шаг 4. Проверьте владельца

Сразу после входа запросите текущего пользователя:

GET /api/user HTTP/1.1
Host: api.gigma.ru
Authorization: Bearer <user_access_token>
Accept: application/json

Проверьте поля фактического ответа API:

• user.login совпадает с email из POST /api/projects;
• user.role.name равно owner;
• user.is_banned равно false;
• user.permissions содержит права для следующего действия.

Если хотя бы одна проверка не прошла, не продолжайте настройку этим токеном. Пример фактического ответа находится в методе «Получите текущего сотрудника».

Если ответ на создание проекта потерян

POST /api/projects не принимает Idempotency-Key, а опубликованный контракт не обещает идемпотентность. Не повторяйте запрос автоматически после разрыва соединения, тайм-аута или неподтверждённого серверного сбоя.

Используйте POST /api/send_password с тем же login только как диагностическую проверку:

• 200 означает, что пользователь с таким email существует. Получите Bearer и проверьте роль owner через GET /api/user;
• ошибка валидации о неизвестном login означает, что пользователя нет, но не доказывает отсутствие частично созданного проекта;
• GET /api/user не возвращает item.id, поэтому потерянный идентификатор проекта этим сценарием восстановить нельзя.

Если ответ 200 от POST /api/projects вместе с item.id не был получен, перед повторным созданием требуется проверить состояние проекта на стороне Gigma. Не меняйте email только для обхода конфликта.

Проверьте результат

Первый запуск завершён, когда выполнены все условия:

1. POST /api/projects вернул 200, а item.id сохранён.
2. POST /api/send_password вернул 200.
3. POST /api/login вернул user.access_token.value.
4. GET /api/user вернул владельца с ролью owner.

Что делать дальше

Для входа клиентов не используйте User Bearer владельца. Клиенты получают Counterparty Bearer через сервис авторизации, а Application задаёт контекст клиентских запросов с помощью App Token.