Lista de comprobación para producción

Una demo necesita una solicitud. Un producto tiene que aguantar timeouts, webhooks duplicados, enlaces caducados y una clave filtrada. Repasa esta lista antes del lanzamiento.

Claves

• La clave vive en el almacén de secretos de tu servidor, nunca en un navegador ni en el paquete de una app.
• Cada entorno y cada servicio tiene su propia clave, para poder revocar una sola.
• Las claves de producción están limitadas a los modelos que usas y tienen un tope diario de gasto.
• Sabes rotar una clave sin cortes (Autenticación).

Crear tareas

• Cada createTask envía un Idempotency-Key derivado de tu propio ID de trabajo, generado una vez y reutilizado en cada reintento.
• Solo se reintentan 429, 500, 503 y 50301, con espera creciente y Retry-After (Errores).
• 400, 40004 y demás errores de «corrige la solicitud» se muestran o se registran, no se reintentan.
• Si muestras precios, cotizas primero, pasas quoteId y expectedCredits y gestionas 40901.
• Un saldo bajo (40201) le llega a una persona —alerta, correo, banner— antes de que lo noten los usuarios.

Recibir resultados

• Las tareas llevan callBackUrl; tu endpoint verifica la firma y rechaza marcas de tiempo antiguas.
• El manejador del webhook responde 2xx rápido y hace el trabajo en segundo plano.
• Las entregas duplicadas se ignoran por request_id.
• Un repaso periódico lee las tareas cuyo webhook nunca llegó.
• Tu código trata cualquier estado distinto de succeeded, failed, expired y canceled como «todavía en marcha».

Archivos

• Los archivos terminados se copian a tu propio almacenamiento (o a tu biblioteca de recursos) en lugar de enlazar la URL firmada, que caduca en unos 20 minutos.
• Guardas taskId, no enlaces firmados.
• Tu código de descarga no envía la clave de API a la URL firmada.
• Los archivos de referencia son enlaces HTTPS públicos al archivo en sí, subidas o recursos, no páginas para compartir.

Costes

• Conoces la unidad de precio de cada modelo (por imagen, por segundo, por solicitud) y los ajustes que la encarecen.
• Las vistas previas y las pruebas usan la resolución más barata y la duración más corta.
• Un tope de gasto frena los bucles desbocados antes de que vacíen el saldo.
• Revisas credits y settled en lugar de suponer que se cobró la estimación.

Monitorización

• Registras request_id, taskId, code y errorCode en cada fallo.
• Vigilas el porcentaje de tareas failed por modelo; una subida repentina suele indicar un cambio de prompt, de entrada o de modelo.
• Mides por modelo el tiempo desde createTask hasta el webhook y avisas ante valores atípicos.
• Alguien del equipo sabe dónde están los logs y la página de uso de la consola de la API.

Contenido

PopNow es un servicio para todos los públicos. Los modelos aplican sus propias reglas de contenido y las solicitudes que rechazan fallan con content_rejected. Si tus usuarios escriben los prompts, explícales en tu propia interfaz por qué se rechazó una solicitud, en vez de mostrar un error en bruto, y déjales cambiarla.