Kling API: согласие и проверка изображения человека

Практические особенности сценария

До загрузки определите владельца решения: кто подтверждает источник файла, цель использования, территорию, срок и право пользователя действовать от имени организации. Не считайте галочку в форме универсальным подтверждением для любых материалов и любых стран. Для спорного случая приложение выбирает review_required и не отправляет файл автоматически. Инженерная команда сохраняет только факт, версию policy и ссылку на внутреннее решение, а не копию согласия в общем техническом логе.

Проверяйте аутентификацию и права на сервере. Браузер не должен передавать gateway key, выбирать внешнего поставщика или самостоятельно обходить очередь проверки. Server-side слой сопоставляет tenant, операцию и разрешённый тип файла, ограничивает размер и MIME-тип, удаляет лишние метаданные, если это соответствует внутренней политике, и выдаёт минимальный operation_id. Не передавайте в обработку паспортные данные, адреса, скрытые идентификаторы и иные поля, не нужные для задачи.

Разделите техническую пригодность и правовую допустимость. Корректный JPEG и успешная загрузка не подтверждают согласие, авторское право или право на коммерческое использование. Аналогично, отказ provider не является юридическим заключением. Интерфейс должен сообщать нейтральный результат проверки, не раскрывая внутренние критерии, а сложные случаи направлять ответственному владельцу процесса. Пользователь не должен получать обещание, что задача будет принята или видео создано.

Постройте минимальный журнал происхождения: request_id, operation_id, tenant, время, версия policy, безопасное решение и хеш файла только при обоснованной политике. Не храните ключи, cookie, полный Authorization, постоянный публичный URL или сам файл дольше необходимого. Ограничьте доступ к журналу и настройте срок хранения отдельно от статуса video-задачи. Журнал помогает расследовать процесс, но сам по себе не доказывает наличие прав.

Перед rollout прогоните синтетические тесты: файл допустимого типа, неподдерживаемый MIME, слишком большой файл, пользователь без прав, отсутствующее решение review и отмена до отправки. Для production включайте новый workflow ограниченно, измеряйте число отказов и время review без публикации этих цифр как гарантий. При изменении policy версионируйте правило, тестируйте регрессию и оставляйте обратимый путь отключения.

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

Для задачи с изображением человека используйте один server-side adapter, собственный request_id и явную политику приложения. Не переносите в клиент ключ, URL внешнего поставщика, model ID или право принимать решение. Kling в этой статье — название поискового сценария; фактические возможности RussiaAPI, поля и доступ проверяют перед запуском.

Сначала опишите, что приложение делает при успехе, отказе, временной недоступности и неизвестном статусе. Такой контракт делает интерфейс предсказуемым и оставляет место для изменения внешней интеграции. Он не обещает, что поставщик примет запрос, сохранит результат или даст одинаковый ответ завтра.

Проверяйте вход на сервере

Клиент может передать неполные, ошибочные или намеренно изменённые данные. Поэтому backend получает аутентификацию и tenant из своей сессии, ограничивает тип, размер и допустимые поля, а затем формирует минимальный запрос для задачи с изображением человека. Секрет хранится только в окружении server-side процесса.

Не логируйте исходный материал, ключ, cookie, Authorization или полный ответ внешней системы. Для поддержки обычно достаточно request_id, tenant, размера, времени, версии adapter и безопасного класса результата. Доступ к этим данным отделяйте от права пользователя запускать операцию.

Версионируйте контракт и тесты

Сохраните версию правила, схему запроса и дату сверки с текущей документацией. Новое обязательное поле, изменение статуса или model ID сначала проверяйте на test tenant. Fixture должен быть синтетическим и обезличенным; в репозиторий не попадают реальные файлы, credentials или временные ссылки.

Добавьте позитивный и негативный набор: корректный минимальный вход, пустое поле, неизвестный параметр, отсутствие прав, слишком большой файл или текст, повтор request_id и временная ошибка. Тест проверяет свой контракт приложения, а не заявляет постоянную характеристику внешней модели.

Состояния, повторы и отмена

Отделяйте принятие запроса от завершения задачи с изображением человека. Внутренние состояния queued, processing, completed, failed и unknown помогают показать честный статус, даже если внешний API меняет названия полей. Не транслируйте наружу сырой текст ошибки или конфигурацию адаптера.

Повтор ограничивают по времени и числу попыток. Перед новым действием сервер проверяет предыдущий operation_id, потому что timeout не доказывает отсутствие побочного эффекта. Если документированный контракт не подтверждает идемпотентность, новый запуск рассматривается как отдельное действие и требует безопасной политики.

Наблюдаемость без лишних данных

Измеряйте только то, что помогает управлять качеством workflow: класс ошибки, длительность, количество отмен, долю неизвестных статусов и повторов. Связывайте данные с request_id, а не с содержимым материала. Метрики не публикуйте как обещание SLA, доступности или точности.

Перед production включайте feature flag для малого test tenant и заранее определяйте условие отката. При аномалии выключите маршрут, сохраните минимальную техническую трассу и вернитесь к контролируемому ручному процессу. Это безопаснее, чем скрыто менять параметры или бесконечно повторять запросы.

Server-side пример

Пример показывает локальную проверку на сервере. Ключи берутся только из окружения; перед запуском подтвердите маршрут, model ID и параметры в актуальном каталоге RussiaAPI.

export function screenPortraitUpload({ authenticated, consentState, mimeType, bytes }) {
  if (!authenticated) return { state: 'access_denied' };
  if (consentState !== 'recorded') return { state: 'review_required' };
  if (!new Set(['image/jpeg', 'image/png']).has(mimeType) || bytes > 8_000_000) return { state: 'invalid_input' };
  return { state: 'approved_for_server_side_submission', policyVersion: '2026-09-18' };
}
// Product policy and actual endpoint requirements must be reviewed before use.

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