Seedance 2.0 API en 2026: acceso, precios y enrutamiento de respaldo

La Seedance 2.0 API ya no es solo una cuestión de descubrimiento de modelos. Para los equipos de producto, las preguntas más difíciles son si la ruta está disponible para el modo de entrada exacto que necesitan, cómo se facturan los usos y qué ocurre cuando un modelo de video de vista previa o de acceso anticipado no está disponible.

Esa distinción importa porque el panorama público de modelos se mueve rápidamente. ByteDance lanzó oficialmente Seedance 2.0 el 12 de febrero de 2026, con entrada multimodal y audio sincronizado como capacidades centrales. A fecha de 27 de julio de 2026, el directorio público de modelos de Flatkey enumera seedance-2.5 como una opción de texto a video e imagen a video de acceso anticipado en 1080p, mientras que seedance-2.0-i2v figura como una ruta de imagen a video basada en uso a 720p.

Esas entradas del catálogo son un punto de partida útil, no un contrato permanente. Una integración de producción debería verificar la disponibilidad del modelo, la modalidad, la resolución, la unidad de precios y la semántica del trabajo antes de cada lanzamiento o campaña importante.

Esta guía explica cómo evaluar el acceso a Seedance en 2026, estimar el coste real del video generado y diseñar un enrutamiento de respaldo que no falle cuando cambie el nombre de un modelo, la ruta del proveedor o una capacidad.

Seedance 2.0 API: la respuesta breve

Los equipos que evalúan la Seedance 2.0 API deben tratarla como un flujo de trabajo multimedia asíncrono con un contrato de capacidades versionado.

En la práctica, eso significa que tu aplicación debería:

1. Validar si la ruta seleccionada admite texto a video, imagen a video, audio, resolución de destino, duración y región.
2. Enviar un trabajo de generación en lugar de esperar una respuesta de estilo chat.
3. Guardar el ID del trabajo del proveedor y tu propia clave de idempotencia.
4. Consultar periódicamente o procesar un webhook hasta que el trabajo alcance un estado terminal.
5. Normalizar la URL de salida, los metadatos, el coste y el motivo del error.
6. Reintentar de forma segura o seleccionar una ruta de respaldo compatible cuando la ruta principal no esté disponible.

Si Seedance es un modelo dentro de un producto más amplio, coloca esta lógica detrás de una capa de enrutamiento en lugar de incrustar las suposiciones de un proveedor en toda tu aplicación.

Qué cambió desde las primeras guías de la Seedance 2.0 API

Los primeros artículos sobre Seedance 2.0 se centraban en encontrar cualquier ruta de API utilizable. Eso ya no es suficiente.

El conjunto de decisiones actual incluye:

• Múltiples versiones de modelo: un equipo puede encontrarse con Seedance 2.0, una ruta 2.0 específica de una modalidad o una ruta Seedance 2.5 más reciente.
• Diferentes combinaciones de capacidades: texto a video, imagen a video, resolución, audio y límites de duración pueden no coincidir entre rutas.
• Estados de acceso cambiantes: el acceso anticipado, las listas de अनुमति, la disponibilidad regional y la elegibilidad de la cuenta pueden cambiar sin que cambie tu producto.
• Diferentes unidades de facturación: el precio del video puede expresarse por segundo, por activo generado, por crédito o mediante una unidad de uso específica de la plataforma.
• Riesgo operativo asíncrono: el tiempo en cola, los timeouts, los envíos duplicados, las URL de salida que expiran y los trabajos fallidos afectan tanto al coste como a la experiencia del usuario.

El resultado es una pregunta de integración más madura: no “¿existe una API de Seedance?”, sino “¿qué ruta satisface esta solicitud hoy y cómo se comportará el producto si esa ruta deja de satisfacerla?”

Instantánea actual del acceso a Seedance para el 27 de julio de 2026

La siguiente tabla es una ayuda de evaluación con fecha. Revise el directorio del modelo en vivo antes de implementar, porque el acceso y los precios pueden cambiar.

Esta instantánea destaca una regla de enrutamiento importante: un modelo más nuevo no es automáticamente un fallback válido para todas las solicitudes, y un modelo más antiguo no es automáticamente intercambiable con la ruta más nueva.

Un fallback válido debe satisfacer las capacidades requeridas por la solicitud. Si el usuario proporcionó una imagen de referencia, el fallback debe admitir imagen a video. Si el producto promete salida 1080p, una ruta que solo ofrece 720p no es equivalente. Si se requiere audio sincronizado, una ruta de video silencioso debe fallar la validación de capacidades antes de enviarse.

Acceso directo al proveedor frente a una pasarela API unificada

Hay dos formas comunes de integrar un modelo Seedance.

Integración directa con el proveedor

El acceso directo puede ser apropiado cuando:

• Seedance es el único modelo de video en el producto.
• La cuenta del proveedor está disponible en la región operativa del equipo.
• El equipo se siente cómodo implementando autenticación específica del proveedor, estados de trabajo, webhooks, facturación y procesos de soporte.
• No existe el requisito de cambiar de modelo sin una versión del cliente.

La desventaja es la acoplamiento operativo. Los campos de solicitud específicos del proveedor, los códigos de error, el manejo de activos y la lógica de facturación pueden propagarse por el producto a menos que el equipo cree su propia capa adaptadora.

Integración con una pasarela unificada

Una pasarela es más útil cuando:

• La generación de video se sitúa junto a cargas de trabajo de chat, imagen, voz o agentes.
• El equipo necesita una sola clave y una sola superficie de facturación entre proveedores de modelos.
• La disponibilidad del modelo o el acceso regional pueden cambiar.
• El producto necesita cuotas centralizadas, listas de अनुमति de modelos, registros de uso o límites de gasto.
• El equipo quiere cambiar el enrutamiento del modelo sin reescribir cada cliente.

Flatkey documenta una capa de acceso estable, límites por clave, listas de अनुमति de modelos y visibilidad de uso. La ventaja clave no es simplemente una configuración más corta. Es la capacidad de aislar un panorama cambiante de proveedores detrás de una única frontera de enrutamiento controlada.

Consulte la guía de enrutamiento de agentes multimodales más amplia para ver el papel arquitectónico de esa frontera en cargas de trabajo de video, imagen, voz y texto.

Construya un contrato de capacidades antes de elegir un modelo

No empiece el diseño de fallback con una lista de nombres de modelos. Empiece con un contrato de solicitud.

Un contrato interno ilustrativo podría verse así:

{
  "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
  }
}

Esto no es un cuerpo de solicitud al proveedor. Es una política a nivel de aplicación que tu enrutador puede evaluar antes de mapear la solicitud a una API específica del proveedor.

El contrato debería separar:

• Requisitos estrictos: modalidad, resolución mínima, audio, duración, región de cumplimiento y formato de salida.
• Preferencias: orden del modelo, nivel de calidad, latencia esperada y objetivo de costo.
• Degradación permitida: si el usuario acepta menor resolución, salida sin audio, menor duración o un estilo visual diferente.
• Límites operativos: tiempo máximo de cola, número de reintentos, presupuesto y plazo límite.

Sin esa separación, el enrutamiento de respaldo se convierte en una apuesta.

Un flujo de trabajo fiable de enrutamiento de respaldo

1. Mantén un registro de rutas en tiempo real

Guarda cada ruta candidata con su capacidad actual y estado de acceso:

• identificador del modelo
• proveedor
• modalidades compatibles
• límites de resolución y duración
• compatibilidad con audio
• restricciones por región o cuenta
• unidad de precio
• estado de salud actual
• hora de la última solicitud exitosa
• hora de la última actualización de evidencia

No asumas que el nombre comercial del modelo contiene suficiente información para enrutar con seguridad.

2. Filtra por capacidades antes que por salud

Primero elimina las rutas que no puedan satisfacer la solicitud. Luego clasifica las rutas restantes por salud, costo, latencia o calidad.

Este orden evita que una ruta saludable pero incompatible reciba una solicitud que no puede cumplir.

3. Separa el fallo de admisión del fallo del trabajo

Las APIs de video pueden fallar antes o después de la creación del trabajo.

Los fallos de admisión incluyen credenciales no válidas, modelos no disponibles, parámetros no compatibles, restricciones de cuenta y límites de tasa. Estos a menudo pueden desencadenar un cambio inmediato de ruta.

Los fallos del trabajo ocurren después de que un proveedor acepta la solicitud. Pueden implicar filtrado de seguridad, errores de generación, tiempos de espera o entrega fallida de activos. Reintentar estos fallos requiere más cuidado porque el primer intento puede haber consumido ya tiempo o computación facturable.

4. Usa idempotencia en tu límite

Asigna un ID de trabajo de aplicación antes de llamar a cualquier proveedor. Guarda cada intento del proveedor bajo ese ID.

Si el cliente reintenta debido a un tiempo de espera de red, tu servicio debería devolver el estado existente del trabajo en lugar de enviar de nuevo una generación idéntica. Esto es especialmente importante para cargas de trabajo de video, donde los duplicados accidentales pueden ser costosos.

5. Normaliza los estados del proveedor

Tu producto no debería exponer una máquina de estados distinta para cada modelo de video. Mapea los estados específicos del proveedor a un conjunto interno pequeño como:

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

Guarde el estado original del proveedor y el error en bruto para la depuración, pero mantenga estable el contrato del producto.

6. Aplique reglas de respaldo limitadas

El respaldo debe ser deliberado, no un bucle sin límites.

Una política práctica podría permitir:

• una ruta alternativa inmediata después de un fallo de admisión
• un reintento después de un fallo de trabajo recuperable
• sin respaldo después de un rechazo por política o seguridad
• sin degradación por debajo de la resolución explícita o el requisito de audio del usuario
• sin nuevo envío después de que se agote el presupuesto o el plazo de la solicitud

7. Registre la decisión de ruta

Para cada trabajo, registre:

• capacidades solicitadas
• ruta seleccionada y motivo
• candidatos rechazados y motivos
• ID del trabajo del proveedor
• marcas de tiempo para cola, inicio y finalización
• duración y resolución de salida
• importe facturado o unidad de uso
• historial de reintentos y respaldo

Estos registros convierten el enrutamiento de una caja negra en un sistema de producto auditable.

Precios de la API de Seedance 2.0: verifique la unidad antes de comparar cifras

La frase “precios de la API de Seedance 2.0” puede ocultar varios modelos de facturación diferentes. Antes de comparar proveedores o pasarelas, confirme todo lo siguiente:

Utilice esta fórmula de carga de trabajo en lugar de comparar una sola cifra destacada:

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

Por ejemplo, un producto que genera 10.000 clips exitosos por mes puede tener una economía muy distinta según la duración media, la resolución, la tasa de reintento y si se incluye audio. Una pequeña mejora en la tasa de éxito en el primer intento puede importar más que una pequeña diferencia en el precio unitario anunciado.

Utilice la página de precios de Flatkey en vivo para obtener información actual sobre planes y compras. Para una implementación seria, registre la fuente exacta del precio y la fecha de verificación en el mismo registro de rutas que almacena las capacidades del modelo.

Migrar de Seedance 2.0 a Seedance 2.5 sin romper el producto

Trate una actualización de modelo como un cambio de ruta controlado, no como un reemplazo de cadena.

Compare los contratos

Pruebe si la nueva ruta preserva:

• tipos de entrada y límites de tamaño
• comportamiento del prompt
• relaciones de aspecto compatibles
• duración y resolución de salida
• comportamiento del audio
• semántica del estado del trabajo
• comportamiento de moderación
• tiempo de vida de la URL del recurso
• informes de costos

Ejecutar una evaluación en sombra

Para una pequeña muestra de solicitudes elegibles, envíe la misma entrada normalizada a ambas rutas fuera del camino crítico para el cliente. Compare la tasa de finalización, la latencia, la calidad de la salida, el costo y los resultados de las políticas.

Usar un despliegue gradual

Traslade un pequeño porcentaje de los trabajos compatibles a la ruta más חדשה. Mantenga la ruta anterior disponible solo donde todavía satisfaga el contrato completo de la solicitud.

Conservar la observabilidad a nivel de ruta

No combine las métricas de Seedance 2.0 y Seedance 2.5 en un único total de “video”. Realice el seguimiento de las versiones por separado para que un despliegue no oculte regresiones.

Errores comunes de integración de la API de Seedance

Tratar la generación de video como una finalización de chat

Los trabajos de video de larga duración necesitan estado duradero, gestión de colas y manejo de recursos. Un patrón de solicitud síncrono crea tiempos de espera frágiles y un mal comportamiento de reintento.

Usar nombres de modelos como política de respaldo

seedance-2.5 y seedance-2.0-i2v no son intercambiables solo porque comparten un nombre de familia. Dirija por capacidades.

Reintentar sin idempotencia

Un tiempo de espera del cliente no prueba que el proveedor haya rechazado la solicitud. Los reintentos a ciegas pueden crear trabajos duplicados con cargo.

Prometer una resolución que el respaldo no puede producir

Si el producto promete 1080p, una ruta de 720p no debería tomar el control en silencio. Pida el consentimiento del usuario o falle de forma clara.

Copiar en la lógica del producto un precio sin fecha

Las páginas de precios cambian. Guarde la fuente de precios y la fecha verificada, y luego haga que el umbral de costo sea configurable.

Ignorar la retención de la salida

Las URL del proveedor pueden expirar. Copie los recursos completados a su propio almacenamiento aprobado antes de exponer una URL de producto duradera.

Una lista de verificación de actualización para una guía emergente de modelos de video

Las páginas de modelos emergentes deben tener un responsable de actualización explícito y un ciclo de evidencia. Revise esta página cada vez que se lance una versión importante de Seedance, y al menos mensualmente mientras el acceso cambie rápidamente.

Cada actualización debería verificar:

1. Anuncio oficial del modelo/versión.
2. Identificador actual del modelo en el catálogo en vivo.
3. Compatibilidad de texto a video e imagen a video.
4. Límites de resolución, duración, audio y región.
5. Estado de acceso, incluidos los requisitos de acceso anticipado o lista de अनुमति.
6. Unidad de precios actual y página de compra.
7. Semántica de creación de trabajos, sondeo, webhook y cancelación.
8. Comportamiento de reintentos, facturación por fallos y retención de salida.
9. Estado público de la ruta y afirmaciones fechadas del artículo.
10. Enlaces internos a la orientación sobre precios y enrutamiento multimodal.

Esta es la diferencia entre un artículo que se posiciona durante poco tiempo y un recurso que sigue siendo útil mientras la demanda de búsqueda todavía se está formando.

Preguntas frecuentes

¿Existe una API de Seedance 2.0?

Sí. Seedance 2.0 es un lanzamiento oficial del modelo de video de ByteDance, y el acceso a la API está disponible a través de rutas de proveedor y de gateway. El identificador exacto del modelo, la modalidad, la región y la elegibilidad de la cuenta dependen de la ruta de acceso, así que verifique el catálogo en vivo antes de implementar.

¿La API de Seedance 2.0 admite texto a video e imagen a video?

Seedance es una familia de modelos de video multimodales, pero las rutas individuales de la API pueden ser específicas de una modalidad. A fecha de 27 de julio de 2026, Flatkey enumera seedance-2.0-i2v para imagen a video y enumera seedance-2.5 para texto a video e imagen a video.

¿Cuánto cuesta la API de Seedance 2.0?

La respuesta depende del proveedor, la ruta, la resolución, la duración, el modo de audio y la unidad de facturación. Confirma si la ruta cobra por segundo, por activo, por crédito u otra unidad de uso, y luego incluye los reintentos, las fallas, el almacenamiento y las tarifas de la plataforma en la estimación de la carga de trabajo.

¿Puede Seedance 2.5 ser una alternativa de respaldo para Seedance 2.0?

Puede ser una candidata cuando cumpla con la misma modalidad, resolución, audio, región, presupuesto y contrato operativo requeridos. No la trates como un reemplazo automático basándote solo en el nombre de la familia del modelo.

¿Qué debería activar una ruta de respaldo?

Los buenos desencadenantes incluyen la indisponibilidad de la ruta, las restricciones de la cuenta, los límites de tasa y los fallos de infraestructura recuperables mediante reintentos. Los rechazos de seguridad, las capacidades no admitidas, los presupuestos agotados y los plazos vencidos normalmente deberían detener el proceso en lugar de activar una generación alternativa no controlada.

El siguiente paso práctico

Antes de elegir una ruta de Seedance, anota las capacidades que promete tu producto y las degradaciones que puede permitir. Luego verifica el catálogo de modelos en vivo y la fuente de precios, ejecuta una pequeña prueba de trabajo asíncrono y registra la fecha de la evidencia.

Si Seedance va a convivir con otros modelos de video, imagen o lenguaje, mantén los detalles del proveedor detrás de una capa de enrutamiento estable. Eso le da a tu equipo una forma controlada de adoptar modelos más nuevos, conservar opciones de respaldo y actualizar las suposiciones de acceso sin reconstruir el producto cada vez que cambie el panorama de los modelos.