API Seedance 2.0 em 2026: acesso, preços e roteamento de fallback

A Seedance 2.0 API já não é apenas uma questão de descoberta de modelos. Para as equipas de produto, as perguntas mais difíceis são se a rota está disponível para o modo de entrada exato de que precisam, como o uso é faturado e o que acontece quando um modelo de vídeo em pré-visualização ou de acesso antecipado não está disponível.

Essa distinção é importante porque o panorama público de modelos está a evoluir rapidamente. A ByteDance lançou oficialmente o Seedance 2.0 em 12 de fevereiro de 2026, com entrada multimodal e áudio sincronizado como capacidades centrais. Em 27 de julho de 2026, o diretório público de modelos da Flatkey lista seedance-2.5 como uma opção de texto para vídeo e imagem para vídeo de acesso antecipado em 1080p, enquanto seedance-2.0-i2v está listado como uma rota de imagem para vídeo baseada em utilização em 720p.

Essas entradas no catálogo são um ponto de partida útil, não um contrato permanente. Uma integração em produção deve verificar a disponibilidade do modelo, a modalidade, a resolução, a unidade de preço e a semântica do trabalho antes de cada lançamento ou grande campanha.

Este guia explica como avaliar o acesso ao Seedance em 2026, estimar o custo real do vídeo gerado e conceber um roteamento de fallback que não falhe quando o nome de um modelo, a rota do fornecedor ou a capacidade mudarem.

Seedance 2.0 API: a resposta curta

As equipas que avaliam a Seedance 2.0 API devem tratá-la como um fluxo de trabalho assíncrono de media com um contrato de capacidade versionado.

Na prática, isso significa que a sua aplicação deve:

1. Validar se a rota selecionada suporta texto para vídeo, imagem para vídeo, áudio, resolução de destino, duração e região.
2. Submeter um trabalho de geração em vez de esperar por uma resposta ao estilo chat.
3. Guardar o ID do trabalho do fornecedor e a sua própria chave de idempotência.
4. Fazer polling ou processar um webhook até o trabalho atingir um estado terminal.
5. Normalizar o URL de saída, os metadados, o custo e o motivo do erro.
6. Repetir em segurança ou selecionar uma rota de fallback compatível quando a rota principal não estiver disponível.

Se o Seedance for apenas um modelo num produto maior, coloque esta lógica atrás de uma camada de roteamento, em vez de incorporar as suposições de um fornecedor por toda a sua aplicação.

O que mudou desde os primeiros guias da Seedance 2.0 API

Os primeiros artigos sobre Seedance 2.0 concentravam-se em encontrar qualquer caminho de API utilizável. Isso já não é suficiente.

A superfície de decisão atual inclui:

• Múltiplas versões de modelo: uma equipa pode encontrar Seedance 2.0, uma rota 2.0 específica de modalidade ou uma rota Seedance 2.5 mais recente.
• Diferentes combinações de capacidades: texto para vídeo, imagem para vídeo, resolução, áudio e limites de duração podem não coincidir entre rotas.
• Estados de acesso em mudança: acesso antecipado, listas de permissão, disponibilidade regional e elegibilidade da conta podem mudar sem que o seu produto mude.
• Diferentes unidades de faturação: o preço de vídeo pode ser expresso por segundo, por ativo gerado, por crédito ou através de uma unidade de utilização específica da plataforma.
• Risco operacional assíncrono: tempo de fila, timeouts, submissões duplicadas, URLs de saída expiradas e trabalhos com falha afetam tanto o custo como a experiência do utilizador.

O resultado é uma questão de integração mais madura: não “existe uma API Seedance?”, mas “qual rota satisfaz este pedido hoje e como se comportará o produto se essa rota deixar de o satisfazer?”

Snapshot atual de acesso ao Seedance para 27 de julho de 2026

A tabela a seguir é uma ferramenta de avaliação desatualizada. Verifique o diretório de modelos ao vivo antes da implementação, porque o acesso e os preços podem mudar.

Este instantâneo destaca uma regra importante de roteamento: um modelo mais novo não é automaticamente um fallback válido para toda solicitação, e um modelo mais antigo não é automaticamente intercambiável com a rota mais nova.

Um fallback válido deve satisfazer as capacidades exigidas pela solicitação. Se o usuário forneceu uma imagem de referência, o fallback deve suportar imagem para vídeo. Se o produto promete saída em 1080p, uma rota apenas em 720p não é equivalente. Se áudio sincronizado for necessário, uma rota de vídeo silencioso deve falhar na validação de capacidade antes do envio.

Acesso direto ao provedor versus um gateway de API unificado

Há duas formas comuns de integrar um modelo Seedance.

Integração direta com o provedor

O acesso direto pode ser apropriado quando:

• Seedance é o único modelo de vídeo no produto.
• A conta do provedor está disponível na região de operação da equipe.
• A equipe está confortável em implementar autenticação específica do provedor, estados de job, webhooks, faturamento e processos de suporte.
• Não há exigência de trocar modelos sem uma nova versão do cliente.

A troca é o acoplamento operacional. Campos de solicitação específicos do provedor, códigos de erro, tratamento de ativos e lógica de faturamento podem se espalhar pelo produto, a menos que a equipe crie sua própria camada de adaptador.

Integração com gateway unificado

Um gateway é mais útil quando:

• A geração de vídeo fica ao lado de cargas de trabalho de chat, imagem, voz ou agentes.
• A equipe precisa de uma única chave e de uma única superfície de faturamento entre provedores de modelos.
• A disponibilidade do modelo ou o acesso regional podem mudar.
• O produto precisa de cotas centralizadas, listas de अनुमति de modelos, registros de uso ou limites de gasto.
• A equipe quer alterar o roteamento de modelos sem reescrever todo cliente.

Flatkey documenta uma camada de acesso estável, limites por chave, listas de अनुमति de modelos e visibilidade de uso. O principal benefício não é apenas uma configuração mais curta. É a capacidade de isolar um cenário de provedores em constante mudança atrás de uma única fronteira controlada de roteamento.

Veja o guia de roteamento de agentes multimodais mais amplo para o papel arquitetural dessa fronteira em cargas de trabalho de vídeo, imagem, voz e texto.

Crie um contrato de capacidade antes de escolher um modelo

Não comece o design de fallback com uma lista de nomes de modelos. Comece com um contrato de solicitação.

Um contrato interno ilustrativo pode ser assim:

{
  "operation": "image_to_video",
  "required": {
    "resolution": "1080p",
    "audio": true,
    "max_queue_seconds": 90
  },
  "preferred_models": [
    "seedance-2.5",
    "seedance-2.0-i2v"
  ],
  "fallback": {
    "allow_lower_resolution": false,
    "allow_silent_output": false,
    "max_attempts": 2
  }
}

Isso não é um corpo de requisição do provedor. É uma política no nível da aplicação que seu roteador pode avaliar antes de mapear a requisição para uma API específica do provedor.

O contrato deve separar:

• Requisitos obrigatórios: modalidade, resolução mínima, áudio, duração, região de conformidade e formato de saída.
• Preferências: ordem do modelo, nível de qualidade, latência esperada e meta de custo.
• Degradação permitida: se o usuário aceita resolução inferior, saída sem áudio, duração menor ou um estilo visual diferente.
• Limites operacionais: tempo máximo na fila, contagem de tentativas, orçamento e prazo final.

Sem essa separação, o roteamento de fallback vira um exercício de adivinhação.

Um fluxo confiável de roteamento de fallback

1. Mantenha um registro de rotas em tempo real

Armazene cada rota candidata com sua capacidade atual e estado de acesso:

• identificador do modelo
• provedor
• modalidades suportadas
• limites de resolução e duração
• suporte a áudio
• restrições de região ou conta
• unidade de precificação
• estado de saúde atual
• hora da última solicitação bem-sucedida
• hora da última atualização de evidências

Não assuma que o nome de marketing do modelo contém informações suficientes para roteamento seguro.

2. Filtre por capacidades antes da saúde

Primeiro remova as rotas que não conseguem atender à solicitação. Depois classifique as rotas restantes por saúde, custo, latência ou qualidade.

Essa ordem evita que uma rota saudável, mas incompatível, receba uma solicitação que não consegue cumprir.

3. Separe falha de admissão de falha de job

APIs de vídeo podem falhar antes ou depois da criação do job.

Falhas de admissão incluem credenciais inválidas, modelos indisponíveis, parâmetros sem suporte, restrições de conta e limites de taxa. Muitas vezes, elas podem disparar uma troca imediata de rota.

Falhas de job acontecem depois que um provedor aceita a solicitação. Elas podem envolver filtragem de segurança, erros de geração, timeouts ou falha na entrega do asset. Repetir essas falhas exige mais cuidado, porque a primeira tentativa pode já ter consumido tempo ou computação faturável.

4. Use idempotência na sua borda

Atribua um ID de job da aplicação antes de chamar qualquer provedor. Armazene cada tentativa de provedor sob esse ID.

Se o cliente tentar novamente por causa de um timeout de rede, seu serviço deve retornar o estado existente do job em vez de enviar outra geração idêntica. Isso é especialmente importante para cargas de trabalho de vídeo, em que duplicatas acidentais podem ser caras.

5. Normalize os estados do provedor

Seu produto não deve expor uma máquina de estados diferente para cada modelo de vídeo. Mapeie os estados específicos do provedor para um pequeno conjunto interno, como:

• queued
• running
• succeeded
• failed_retryable
• failed_terminal
• cancelled

Armazene o estado original do provedor e o erro bruto para depuração, mas mantenha o contrato do produto estável.

6. Aplicar regras de fallback limitadas

O fallback deve ser deliberado, não um loop sem limites.

Uma política prática pode permitir:

• uma rota alternativa imediata após uma falha de admissão
• uma tentativa após uma falha de job recuperável
• nenhum fallback após uma rejeição por política ou segurança
• nenhum rebaixamento abaixo da resolução explícita do usuário ou da exigência de áudio
• nenhuma nova submissão após o orçamento ou o prazo da solicitação se esgotar

7. Registrar a decisão de roteamento

Para cada job, registre:

• capacidades solicitadas
• rota selecionada e motivo
• candidatos rejeitados e motivos
• ID do job do provedor
• carimbos de data/hora para fila, início e conclusão
• duração e resolução da saída
• valor cobrado ou unidade de uso
• histórico de tentativas e fallback

Esses registros transformam o roteamento de uma caixa-preta em um sistema de produto auditável.

Preços da API Seedance 2.0: verifique a unidade antes de comparar números

A expressão “preços da API Seedance 2.0” pode ocultar vários modelos de cobrança diferentes. Antes de comparar provedores ou gateways, confirme tudo o que segue:

Use esta fórmula de carga de trabalho em vez de comparar um único número de destaque:

monthly generation cost =
successful output seconds
× effective rate per second
+ retry and failure cost
+ storage and delivery cost
+ platform or support cost

Por exemplo, um produto que gera 10.000 clipes bem-sucedidos por mês pode ter economias muito diferentes dependendo da duração média, resolução, taxa de retentativa e se o áudio está incluído. Uma pequena melhoria na taxa de sucesso na primeira tentativa pode importar mais do que uma pequena diferença no preço unitário anunciado.

Use a página de preços da Flatkey ao vivo para obter informações atuais sobre planos e compras. Para uma implementação séria, registre a fonte exata do preço e a data da verificação no mesmo registro de roteamento que armazena as capacidades do modelo.

Migrando do Seedance 2.0 para o Seedance 2.5 sem quebrar o produto

Trate uma atualização de modelo como uma mudança de rota controlada, não como uma substituição de string.

Comparar contratos

Teste se a nova rota preserva:

• tipos de entrada e limites de tamanho
• comportamento do prompt
• proporções de tela suportadas
• duração e resolução da saída
• comportamento do áudio
• semântica do status do job
• comportamento de moderação
• tempo de vida da URL do ativo
• relato de custos

Executar avaliação em sombra

Para uma pequena amostra de solicitações elegíveis, envie a mesma entrada normalizada para ambas as rotas fora do caminho crítico do cliente. Compare a taxa de conclusão, a latência, a qualidade da saída, o custo e os resultados de política.

Usar um rollout em etapas

Mova uma pequena porcentagem dos jobs compatíveis para a rota mais nova. Mantenha a rota anterior disponível apenas onde ela ainda satisfaça o contrato completo da solicitação.

Preservar a observabilidade em nível de rota

Não agrupe as métricas do Seedance 2.0 e do Seedance 2.5 em um único total de “vídeo”. Acompanhe as versões separadamente para que um rollout não esconda regressões.

Erros comuns de integração da API Seedance

Tratar geração de vídeo como conclusão de chat

Jobs de vídeo de longa duração precisam de estado durável, gerenciamento de fila e tratamento de ativos. Um padrão de solicitação síncrona cria timeouts frágeis e comportamento ruim de retry.

Usar nomes de modelos como política de fallback

seedance-2.5 e seedance-2.0-i2v não são intercambiáveis apenas porque compartilham um nome de família. Faça o roteamento por capacidades.

Repetir sem idempotência

Um timeout do cliente não prova que o provedor rejeitou a solicitação. Repetições cegas podem criar jobs duplicados faturáveis.

Prometer uma resolução que o fallback não consegue produzir

Se o produto promete 1080p, uma rota de 720p não deve assumir o controle silenciosamente. Peça consentimento do usuário ou falhe de forma clara.

Copiar um preço sem data para a lógica do produto

Páginas de preços mudam. Armazene a fonte de preços e a data verificada e, em seguida, torne o limite de custo configurável.

Ignorar a retenção da saída

As URLs do provedor podem expirar. Copie os ativos concluídos para seu próprio armazenamento aprovado antes de expor uma URL durável do produto.

Uma lista de verificação de atualização para um guia emergente de modelo de vídeo

Páginas de modelos emergentes devem ter um responsável explícito pela atualização e um ciclo de evidências. Revise esta página sempre que uma grande versão do Seedance for lançada, e pelo menos mensalmente enquanto o acesso estiver mudando rapidamente.

Cada atualização deve verificar:

1. Anúncio oficial do modelo/versão.
2. Identificador atual do modelo no catálogo ao vivo.
3. Suporte a texto para vídeo e imagem para vídeo.
4. Limites de resolução, duração, áudio e região.
5. Estado de acesso, incluindo acesso antecipado ou requisitos de lista de permissão.
6. Unidade de preço atual e página de compra.
7. Semântica de criação de job, polling, webhook e cancelamento.
8. Comportamento de retry, cobrança em caso de falha e retenção da saída.
9. Status público da rota e alegações datadas do artigo.
10. Links internos para preços e orientações de roteamento multimodal.

Essa é a diferença entre um artigo que ranqueia brevemente e um ativo que continua útil enquanto a demanda de busca ainda está se formando.

Perguntas frequentes

Existe uma API Seedance 2.0?

Sim. Seedance 2.0 é um lançamento oficial de modelo de vídeo da ByteDance, e o acesso à API está disponível por meio de rotas de provedor e gateway. O identificador exato do modelo, a modalidade, a região e a elegibilidade da conta dependem do caminho de acesso, então verifique o catálogo ao vivo antes da implementação.

O Seedance 2.0 API oferece suporte a text-to-video e image-to-video?

Seedance é uma família de modelos de vídeo multimodais, mas rotas de API individuais podem ser específicas de uma modalidade. Em 27 de julho de 2026, a Flatkey lista seedance-2.0-i2v para image-to-video e lista seedance-2.5 para text-to-video e image-to-video.

Quanto custa o Seedance 2.0 API?

A resposta depende do provedor, da rota, da resolução, da duração, do modo de áudio e da unidade de cobrança. Confirme se a rota cobra por segundo, ativo, crédito ou outra unidade de uso e, em seguida, inclua novas tentativas, falhas, armazenamento e taxas da plataforma na estimativa da carga de trabalho.

O Seedance 2.5 pode ser um fallback para o Seedance 2.0?

Ele pode ser um candidato quando atende à mesma modalidade obrigatória, resolução, áudio, região, orçamento e contrato operacional. Não o trate como um substituto automático com base apenas no nome da família do modelo.

O que deve acionar uma rota de fallback?

Boas situações de acionamento incluem indisponibilidade da rota, restrições de conta, limites de taxa e falhas de infraestrutura passíveis de nova tentativa. Rejeições de segurança, capacidades não suportadas, orçamentos esgotados e prazos expirados normalmente devem interromper o processo, em vez de acionar uma geração alternativa sem controle.

O próximo passo prático

Antes de escolher uma rota Seedance, anote as capacidades que seu produto promete e as degradações que ele pode permitir. Em seguida, verifique o catálogo de modelos em tempo real e a fonte de preços, execute um pequeno teste de job assíncrono e registre a data da evidência.

Se o Seedance ficar ao lado de outros modelos de vídeo, imagem ou linguagem, mantenha os detalhes do provedor atrás de uma camada de roteamento estável. Isso oferece à sua equipe uma forma controlada de adotar modelos mais novos, preservar opções de fallback e atualizar as suposições de acesso sem reconstruir o produto toda vez que o cenário de modelos mudar.