ym88659208ym87991671
BACKEND | Документация для разработчиков

BACKEND

Обновлено 1 сентября 2026

Получение и обновление токенов

На стороне бэкэнда обеспечьте надежную обработку токенов авторизации, включая своевременное обновление access-токена и refresh-токена. Токены периодически истекают, и важно поддерживать актуальность сеанса пользователя.

Подробнее о работе access-токена и refresh-токена

Генерация и передача идентификатора пользователя

Для идентификации пользователя на сервере партнера организуйте генерацию уникального идентификатора пользователя (userID для МП, sessionId для Web) и его передачу на сторону приложения. Этот идентификатор создается вами и используется в коммуникациях между SDK -> ваш backend для идентификации пользователя и нахождения токена для последующей передачи на сервер ЕЛК (Единый личный кабинет).

Правила формирования userID/sessionId:

  • уникален для каждого пользователя;
  • генерируется и хранится на стороне партнера;
  • передается при инициализации SDK.

Прокси-обработка запросов

Настройте обработку запросов, поступающих от SDK, как прокси-сервер.

Последовательность действий:

  1. Получение запроса от SDK. Примите HTTP-запросы от фронтальной стороны.

  2. Передача запроса на сервер ЕЛК. Преобразуйте полученный запрос в нужный формат и отправьте его на сервер ЕЛК.

  3. Обработка ответа от ЕЛК. Получите ответ от нашего сервера и верните его обратно в SDK

Если ответ требует дополнительной обработки (например, изменение имени или аватара пользователя), воспользуйтесь рекомендациями из специального раздела (Изменение аватара и имени пользователя)

Рассмотрим простые примеры того, как обрабатывать запросы от SDK и передавать их далее на сервер ЕЛК, а затем возвращать обработанные ответы в SDK.

Пример обработки запроса и ответа по виджетам ЕЛК

1. Запрос от SDK на сервер партнера

SDK отправляет на ваш сервер (url переданный в partnerProfileUrl при инициализации SDK) следующий запрос:

#ИмяТипОбязательныйОписаниеПример
1AuthorizationЗаголовокДаТокен сессии. К значению userID/sessionId (полученному при инициализации SDK) в начале добавляется «Bearer ».Bearer DC3641EC-A0C1-F61A-B2DE-A331C0B2E20F
2[Ключ от партнера]ЗаголовокНетОдин или несколько ключей и их значения, полученные от партнера при инициализации в параметре headersELK.first: one
User-Agent: Ktor client
3AcceptЗаголовокДаОжидаемый тип ответа.application/json
4Content-TypeЗаголовокДаТип передаваемых данных.application/json
2. Запрос на сервер ЕЛК от сервера Партнера

Процесс инициализации вызова ЕЛК

  1. Предварительная проверка сервером партнера

    • Перед инициализацией вызова сервера ЕЛК, сервер партнера проверяет активность access-токена пользователя.
    • При необходимости сервер партнера обновляет его ("подогрев").

  2. Условие: Отсутствие токенов

    • Если сервер партнера не находит у себя ни активного access-токена, ни refresh-токена пользователя,
    • То сервер партнера должен вернуть в SDK ошибку 401 Unauthorized.

Формат ответа об ошибке:

   HTTP/1.1 401 Unauthorized
   {
       "error": "unauthorized_client"
   }
  1. Запрос данных для виджетов ЕЛК
    • При успешной проверке токенов сервер партнера направляет запрос на сервер ЕЛК.
    • Адрес запроса получен в запросе от SDK
    • Тип запроса GET

Параметры запроса

№Имя (Name)Расположение (In)ОписаниеОбязательный
1infoSourcequeryСписок источников данных. Получен от SDK.Да
2widgetNamequeryНаименование шаблона. Получен от SDK.Да
3x-introspect-rquidheaderУникальный идентификатор сообщения (maxLength=32, pattern=([0-9][a-f][A-F]){32}). Необходим для журналирования. Для генерации можно использовать UUID/GUID, удалив разделители «-».Да
4AuthorizationheaderПолученный ранее access-токен. Должен иметь префикс Bearer. Пример: Bearer DC3641EC-A0C1-F61A-B2DE-A331C0B2E20F. `Да

Пример запроса (cURL):

   curl --request GET \
     'https://oauth-ift.sber.ru/api/v1/userdata?infoSource=[Тип источника данных]&widgetName=[Название шаблона]' \
     --header 'x-Introspect-RqUID: 55286baf3d4548da8d2252b2a8337f20' \
     --header 'Authorization: Bearer 4cf09bfb-ce00-4847-9f24-28377692baf7'
3. Обработка ответа сервером Партнера

Сервер партнера без дополнительной обработки на своей стороне возвращает ответ в SDK.

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

 {
   "title": "Иван К",
   "icon": "https://stat.online.sberbank.ru/SBERBANKID/icons/CODE16206.png",
   "iconSize": "40",
   "badge": "https://id.sber.ru/profile/external_partners/elk_assets/badge-gradient.png",
   "initials": "ИК",
   "value": "+7 900 000 00 00",
   "click": {
      "browserUrl": "https://id.sber.ru/profile/?utm_source=partner_profile&utm_medium=app_samokat&utm_campaign=button_nmt"
   }
 }
Параметр (путь)ОписаниеОбязательность
titleИмя пользователяДа
iconСсылка на аватарку (пока не передается)Нет
iconSizeРазмер аватаркиНет
badgeСсылка на иконку SberIDДа
initialsИнициалы пользователяНет
valueНМТНет
clickИнформация о переходе при нажатии на виджетНет
.browserUrlОткрытие ссылки в браузере устройстваНет
.deepLinkUrlОткрытие по диплинкуНет
.nativeUrlОткрытие нативной шторкиНет
.ssoБесшовный переход через app_tokenДа
..webLinkСсылка на поверхность партнераДа
..openInГде открывать: browser или webviewНет
..clientIdID партнера для переходаНет

Таким образом, выполнение перечисленных шагов позволит эффективно организовать back-end взаимодействие с сервисом ЕЛК и минимизировать возможные проблемы интеграции.

Заметили ошибку?
Выделите текст и нажмите
Ctrl
+
Enter
, чтобы сообщить нам об ошибке