Здравствуйте!
Необходимо обращаться из 1С к некоторому API с периодичностью один раз в 30 сек(сделаю регламентным заданием).
При обращении к api в заголовках нужно указывать токен доступа. Токен доступа можно получить по запросу к тому же api. Время жизни токена составляет 10 часов, после чего его нужно обновлять повторным запросом.
Вопрос: где лучше хранить токен при такой схеме работы?

Я сделал в параметрах сеанса, там же храню срок годности токена

Спасибо, сейчас попробую.
Мне думалось что работа с параметрами сеанса в фоновых заданиях недоступна

По хорошему,в регистре сведений
за 10 часов и сервер рестартануть могут успеть.

(3) да и в типовых вроде как конфиденциальные приблуды в РС хранят

(3) регистр сведений думаю не нужен, если при запросе получили 403 ошибку, то нужно обновить токен.
(4) как раз таки токен конфиденциальная инфа и ее не стоит хранить в РС

(2)что то не получается через параметры сеанса,
вот тестовый код:
        Попытка
        Токен = ПараметрыСеанса.ТокенLOGO;
        ЗаписьЖурналаРегистрации("Токен лого",,,,"токен получен");
    Исключение
        ЗаписьЖурналаРегистрации("Токен лого",,,,"ошибка - " + ОписаниеОшибки());
        ПараметрыСеанса.ТокенLOGO = "тест токен";
    КонецПопытки;      

при каждом запуске происходит исключение, что попытка получения не инициализированного параметра сеанса, получается между вызовами фонового задания параметры сеанса очищаются?

(6) - (1)

(6) Вообще да. Просто у меня была несколько другая задача: срок действия токена небольшой, а задание запускается раз в сутки, плюс еще могут подключаться пользователи под своим логином паролем, на который выдается свой токен.
В твоем случае видимо да, РС больше подойдет.

инициплизация параметров сеанса,есть такая процндура в модуле сеанса.
туда нужно записать пустое значение,чтобы получив его гарантированно получать токен заново и писать его в параметры сеанса.

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

Я делал через регистр,в нём ещё храню время окончания действия. Если срок истёк или ошибка токена, то обновляю его.

(10) + но у меня по заданию учетка была одна на несколько пользователей.

(1) Каждое регламентное это отдельный сеанс.
А параметры сеанса потом так и называются, что инкапсулированиы в сеансе.
(0) бахай РС или константу (время жизни 10 часов, в принципе примлимо)

(12) Ну мнемонически - пишем значение во много раз реже чем читаем (читаем раз в 30 сек. меняем раз в 10 часов) - допустимо и в константу положить. Ибо вкорячивать РС ради одной записи выглядит тоже не очень

(13) так и придется делать скорее всего(хотя мне этот вариант не очень нравится, костыль какой-то)
есть еще вариант писать токен в файл на сервере