Время актуальности requestId (в секундах)

Настройка задаёт срок жизни кэша проценки на сервере: в течение указанного числа секунд повторное обращение с тем же requestId может получить уже сохранённые результаты без полного повторного опроса поставщиков. Так снижается нагрузка на API и ускоряется повторный показ той же проценки.

#Где находится

Настройки → Общие настройки → вкладка «Проценка» → блок «Запросы к поставщикам и кэш проценки» → поле «Время актуальности requestId (в секундах)»

#Допустимые значения

• целое число ≥ 0 (секунды);
• по умолчанию в настройках обычно 300 (5 минут).

#Как это работает

• При проценке клиенту выдаётся requestId — метка одного «прогона» поиска по номеру. Результаты по поставщикам накапливаются на сервере и привязываются к этому идентификатору.
• Пока с момента создания записи кэша прошло меньше, чем указано в поле, ответ может отдаться из кэша (быстрее, без лишних запросов к поставщикам).
• Если прошло больше секунд, чем TTL, кэш для этого requestId считается устаревшим — нужна новая проценка (новый requestId или повторный сбор данных).
• 0 — режим «кэш не использовать при проверке»: полная выдача из сохранённого requestId не подставляется как актуальная; нагрузка на поставщиков выше, зато нет «залипания» на старых ценах из кэша.

#Рекомендуемые значения

• 300 секунд (5 минут) — разумный старт для большинства витрин.
• 60–180 секунд — если цены и наличие должны обновляться чаще.
• 0 — только если осознанно нужны всегда свежие запросы к поставщикам; нагрузка на систему и API вырастет.

#Что проверить после изменения

• скорость повторной проценки того же артикула в пределах TTL;
• насколько данные совпадают с ожиданием «как у поставщика сейчас»;
• нет ли превышения лимитов у поставщиков при частых перезапросах (особенно при 0).