transcrevo docs

Migrar para cá

De outra API de transcrição ou de um script próprio com modelo aberto: o mapa de conceitos, o que muda no seu código e o que conferir antes de virar a chave.

Duas origens cobrem quase toda migração: uma API de transcrição que você já usa, ou um script seu rodando um modelo aberto. As duas mudam pouco código; o que muda mesmo é onde ficam as decisões.

Vindo de outra API de transcrição

O desenho é o mesmo que quase toda API assíncrona usa, então a tradução é quase mecânica:

O que você tem hojeAqui
Criar job com URL do áudioPOST /v1/transcripts com url
Criar job com arquivoPOST /v1/uploads (corpo bruto) e depois uploadId
Polling do jobGET /v1/transcripts/{id}, ou ?wait=30 para não ficar perguntando
Callback de conclusãowebhookUrl na criação
Separação de falantesspeakers: true, 3 ou "2-5"
Vocabulário / boost de termosglossary, { "o que ele ouve": "o que escrever" }
Seu id no jobexternalId (e metadata para o resto)
Palavras com tempowords[], em segundos decimais
Blocos para legendautterances[]

Cinco diferenças que costumam pegar:

  1. Tempo em segundos decimais, nunca em milissegundos. 1.5 é um segundo e meio. Um cliente que multiplica por 1000 gera legenda mil vezes fora do lugar e o erro só aparece no player.
  2. Dinheiro na menor unidade da moeda, com fração. cost: 0.0167 é um sexagésimo de dólar. Guardar em coluna inteira zera o valor.
  3. A saída não é determinística e não existe seed. O mesmo arquivo pode voltar com diferenças pequenas. Não compare execuções byte a byte: guarde o transcrito entregue, cujo id é permanente.
  4. Um idioma por arquivo. A detecção é automática, mas ela escolhe UM idioma para o áudio inteiro: não há marcação de trechos por idioma.
  5. Sem SDK. É HTTP puro com a chave no header Authorization: Bearer, e o spec OpenAPI gera cliente na sua linguagem se você quiser um.

Antes de virar a chave, confira com o seu próprio áudio (não com uma amostra nossa): o playground do painel põe o transcrito daqui e o que você já tem lado a lado, no mesmo áudio, com o som tocando junto. É a única comparação que responde pela SUA base.

Vindo de um script próprio com modelo aberto

Se hoje você roda o modelo em uma máquina sua, o que muda não é a qualidade do texto: é quem carrega a operação.

O que some do seu lado:

  • A fila e o retry quando a máquina morre no meio do arquivo.
  • Ligar e desligar GPU conforme a demanda (e pagá-la parada).
  • Decodificar container esquisito, áudio truncado, arquivo que não é áudio.
  • Diarização, pontuação e alinhamento de palavra, cada um com o próprio modelo.
  • Manter tudo isso rodando enquanto você trabalha em outra coisa.

O que passa a ser seu:

  • Uma chamada HTTP e um webhook (ou ?wait=).
  • O custo por hora de áudio, publicado, sem GPU ociosa.

O caminho mais curto é manter o seu script rodando e mandar a mesma leva para cá por uns dias, comparando no seu material antes de desligar qualquer coisa. A conta nova já vem com crédito suficiente para isso.

Lista de conferência

  • Chave no servidor, nunca no navegador nem no app distribuído.
  • Idempotency-Key na criação, chaveada pelo primeiro uploadId (por quê).
  • Tratar error.retryable em vez de manter a sua tabela de retry.
  • Guardar requestId no log das falhas.
  • webhookUrl (com verificação de assinatura) ou ?wait= no lugar do laço de polling.
  • Ler GET /v1/limits em vez de gravar os tetos no código.
  • Decidir a retenção: retentionDays por job, se o seu material pede prazo.
  • Conferir o custo estimado contra a primeira fatura real: a cobrança é por duração medida do áudio, não por arquivo nem por requisição.

On this page