Авторизация и безопасность

Bearer-токен для всех схем. Заголовок Authorization. Ответ 401.

Правило интеграции

Для всех схем (DBS, FBS, FBO) запросы авторизуются Bearer-токеном — как в DBS.

Заголовок:

Authorization: Bearer <token>

Это единственный способ для тестов и интеграции. Не слать X-Cabinet-Id и не собирать вызов из пары Client-Id + Api-Key.

Сейчас в OpenAPI FBS/FBO указаны заголовки Client-Id и Api-Key. Это расхождение с DBS, его поправят в ближайшей выкатке. Пока тестируйте по правилу DBS.

В контракте DBS токен передаётся в заголовке Authorization, формат значения — Bearer <token>. Методы — POST, тело JSON (Content-Type: application/json). Боевой URL даёт витрина (в контракте указан пример api.example.com).

HTTP 401

Нет токена, токен неверный или просрочен — витрина отвечает 401 «Ошибка авторизации». Тело — ApiError.

error_type: ERROR_TYPE_UNAUTHORIZED → HTTP 401.

У ApiError нет обязательных полей. Обычно приходят error_type, code, message, details. code — свободная строка, список значений для 401 в контракте нет.

{
  "error_type": "ERROR_TYPE_UNAUTHORIZED",
  "code": "string",
  "message": "Ошибка авторизации",
  "details": {}
}

Рядом по тому же ApiError (не ошибка заказа): ERROR_TYPE_RATE_LIMIT → 429, ERROR_TYPE_INTERNAL → 500, ERROR_TYPE_BAD_REQUEST → 400. Подробности — в обработке ошибок.

Сейчас в OpenAPI FBS/FBO в error_type нет ERROR_TYPE_BAD_REQUEST. Это то же расхождение, его поправят. Ожидайте 400 как в DBS.

Пример запроса

В списке заказов обязательны filter и limit. cursor можно не слать.

POST /v1/order/dbs/list
Authorization: Bearer <token>
Content-Type: application/json

{
  "filter": {
    "status": ["NEW"]
  },
  "limit": 100
}

Пустой filter: {} допустим: поля внутри фильтра не обязательны, опущенные поля список не сужают (см. общие концепции).

Как получить токен

Рекомендация. Токен выдаёт витрина (личный кабинет продавца или OAuth). При 401 обновите токен по правилам этой витрины. Не завязывайте проверки на конкретную строку code в теле 401.