Гайд · TNWS AI

Как получить временный токен AssemblyAI для streaming в браузере

5 мин

Серверная выдача temporary token, expires_in_seconds, max_session_duration_seconds и подключение клиента без раскрытия API-ключа.

Практическая задача

Материал отвечает на запрос «как получить временный token AssemblyAI streaming». Параметры сверены 12 сентября 2026 года с официальной документацией AssemblyAI. Результат принимается только после проверки структуры и контрольных данных: успешный HTTP-код сам по себе не доказывает правильность расшифровки.

Применимость

Клиентский streaming, где постоянный API key нельзя передавать браузеру. Temporary token создаётся доверенным backend.

Перед внедрением зафиксируйте поколение API или SDK, speech model, язык, регион и формат аудио. Каталог моделей и совместимость функций меняются. Постоянный ASSEMBLYAI_API_KEY держите на backend или в менеджере секретов; в клиентское приложение допустим только специально созданный временный streaming token.

Подтверждённые данные

  • Endpoint — https://streaming.assemblyai.com/v3/token.
  • Постоянный ключ backend передаёт в Authorization.
  • expires_in_seconds задаёт срок использования token.
  • max_session_duration_seconds опционально ограничивает длительность начатой сессии.

AssemblyAI разделяет pre-recorded, real-time и Sync STT. Первый режим создаёт асинхронный transcript, streaming работает в WebSocket-сессии, а Sync предназначен для короткого завершённого клипа. У них разные endpoints, состояния и ограничения; переносить параметры между режимами без проверки нельзя.

Подготовка контрольного файла

  1. Создайте обезличенную запись с известным текстом. Для диаризации нужны известные границы и достаточная речь каждого участника; для тональности — заранее размеченные предложения.
  2. Выполните ffprobe и запишите container, codec, sample rate, channels и duration. Расширение .wav или .mp3 не гарантирует фактическое содержимое.
  3. Составьте эталон: обязательные слова, язык, число спикеров, интервалы или ожидаемые captions.
  4. Для A/B-теста используйте идентичные байты и меняйте один параметр. Иначе разницу нельзя отнести к модели, prompt или keyterms.
  5. Не используйте реальные платёжные, медицинские и паспортные сведения. Синтетический секрет должен легко находиться точным поиском.
file: control.wav
duration_seconds: 30
sample_rate: 16000
channels: 1
expected_language: ru
expected_phrase: "заказ сорок два готов"
contains_real_personal_data: false

Это форма карточки, а не универсальные требования. Заполните её фактическими данными файла. Для streaming добавьте размер chunk, период отправки и момент намеренного обрыва.

Настройка по шагам

  1. Создайте отдельный ключ тестовой среды и экспортируйте его как ASSEMBLYAI_API_KEY. Не печатайте значение в CI и shell history.
  2. Выберите один режим: pre-recorded, streaming или Sync. Сверьте endpoint, модель и ограничения длительности.
  3. Запустите минимальный шаблон ниже без автоматических retry. Так сохранятся исходный HTTP-код и тело ошибки.
  4. Для async различайте completed, error и промежуточные статусы. Ограничьте polling общим deadline и добавьте backoff.
  5. Разберите только документированные поля. Отсутствующее поле — ошибка контракта, а не пустая строка.
  6. Сравните ответ с эталоном: Браузер получает только короткоживущий token; постоянного ключа нет в DevTools, просроченный token отвергается.
  7. Выполните отрицательный тест: неверный формат, истёкший token, неподдерживаемая длина или повторный webhook. Система обязана отказать предсказуемо.

Готовый шаблон

params={'expires_in_seconds':60,'max_session_duration_seconds':900}
r=requests.get('https://streaming.assemblyai.com/v3/token',params=params,headers={'Authorization':os.environ['ASSEMBLYAI_API_KEY']})
return {'token':r.json()['token']}

Идентификаторы и файлы заменяются значениями из текущей документации и вашей среды. Никогда не вставляйте рабочий ключ в статью или frontend. После теста сохраните transcript id, request metadata и исходный JSON без секрета.

Вход и ожидаемый выход

Контрольный вход должен быть реалистичным для продукта: голосовое сообщение, звонок, встреча или ролик. Один диктор в тишине не проверяет контакт-центр, а десятисекундный диалог не показывает устойчивость speaker labels. Подготовьте 20–50 обезличенных кейсов, включая шум, акцент, паузы и редкие термины.

Ожидаемый выход: Браузер получает только короткоживущий token; постоянного ключа нет в DevTools, просроченный token отвергается.

Проверка текста включает не только непустое поле. Считайте WER или долю обязательных фраз, отдельно фиксируйте ошибки имён, сумм и артикулов. Для streaming сверяйте отсутствие дублей partial/final, для subtitles — порядок таймкодов, для webhook — идемпотентность.

Критерии приёмки

  • ключ только backend
  • TTL короткий
  • session cap есть
  • no-store задан
  • expiry протестирован

Сохраняйте model used, language code, transcript id, длительность, confidence, latency и итог PASS/FAIL. Порог confidence определяйте на своей размеченной выборке: универсального безопасного значения для всех микрофонов и языков нет.

Ошибки и что не делать

  • Генерировать token в браузере.
  • Кэшировать endpoint публичным CDN.
  • Не ограничивать частоту выдачи.

Не активируйте все возможности одним запросом до получения baseline. Добавляйте speaker labels, language detection, prompting и анализ по одному. Не повторяйте 400: сначала исправьте контракт. Для 429 и 5xx используйте ограниченные попытки с экспоненциальной задержкой и jitter.

Не принимайте метку speaker за личность, sentiment за намерение и языковую подсказку за фильтр. Не публикуйте низкоуверенные имена автоматически. Аудио и transcript защищайте независимо от API-ключа: минимизируйте доступ, задайте срок хранения и удаляйте тестовые данные.

Промпт для независимого аудита

Проверь интеграцию AssemblyAI для задачи «как получить временный token AssemblyAI streaming».
Используй только приложенные параметры, эталон и JSON-ответ.
Верни: проверка | ожидание | факт | PASS/FAIL | исправление.
Отдельно проверь status, model used, language, временные интервалы,
отсутствующие поля, дубли и утечки контрольных данных.
Не додумывай отсутствующий текст и не считай HTTP 200 достаточным.

Перед передачей логов второй модели удалите ключ и лишние персональные данные. Окончательный PASS вычисляет код по формальным условиям; генератор используется только как помощник по диагностике.

Проверка на серии

Разделите данные на контрольный набор и новые примеры. После смены модели, prompt, keyterms, SDK или аудиокодека прогоняйте обе части. Отчёт должен показывать технический success rate, WER или recall, полноту финальных сегментов и долю результатов, прошедших бизнес-валидацию.

Полезная метрика — задержка и стоимость одного принятого результата с учётом ошибок, повторов и ручной проверки. Среднее время удачного HTTP-запроса скрывает плохие transcripts и зависшие сессии.

FAQ

Достаточно ли одного успешного файла?

Нет. Нужны серия, граничные случаи и отрицательный тест.

Можно ли хранить постоянный ключ в браузере?

Нет. Для streaming-клиента выдавайте временный token с backend.

Нужно ли сохранять transcript id?

Да, он нужен для чтения, диагностики, повторной обработки и удаления async transcript.

Можно ли доверять confidence без эталона?

Нет. Калибруйте пороги на данных своего продукта.

Официальный источник

Частые вопросы

Достаточно ли HTTP 200?

Нет, проверьте status и бизнес-условие.

Можно ли хранить ключ в браузере?

Нет, используйте временный streaming token.

Нужно ли сохранять transcript id?

Да, для чтения, диагностики и удаления.

Нужен ли отрицательный тест?

Да, он доказывает корректную обработку отказов.

Читайте также

Комментарии

Пока тихо. Скажите первое слово