Cómo funciona
Una conversión tiene cuatro pasos: averiguamos qué es realmente el archivo, buscamos una ruta hasta el formato que pediste, la ejecutamos y te entregamos el resultado. Aquí está cada uno.
Detectamos el formato por los bytes, no por el nombre
Un archivo llamado report.pdf no es necesariamente un PDF, y un archivo sin extensión suele seguir siendo identificable. Por eso lo primero que hacemos es leer los primeros bytes de la subida y compararlos con firmas de formato conocidas.
Esto importa más de lo que parece. Fiarse de la extensión hace que un archivo renombrado falle con un error confuso o, peor, que se pase a la herramienta equivocada. Leer los bytes hace que un archivo mal etiquetado se convierta igualmente bien, y que uno que de verdad no es lo que dice se rechace con claridad.
Las conversiones son un grafo, no una lista
Cada conversión admitida es una arista entre dos formatos, y cada arista registra su fidelidad, su coste aproximado y el mayor tamaño de entrada que acepta. De ese grafo se generan las páginas de formatos, y se publica íntegro a través de la API.
Si no existe ninguna arista entre los dos formatos que has nombrado, se te dice al instante y no después de subir el archivo. Nada se enruta en silencio a través de un formato intermedio con pérdidas para aparentar que una conversión funciona.
Las conversiones rápidas se ejecutan al vuelo; las lentas se encolan
Redimensionar una imagen termina en bastante menos de un segundo, así que se ejecuta dentro de la propia petición y la respuesta ya trae el resultado. Renderizar un documento largo o transcodificar vídeo no, así que esos trabajos se encolan y los recoge un grupo de procesos aparte.
Nunca tienes que adivinar cuál te ha tocado. Un trabajo terminado vuelve con el resultado; uno encolado vuelve con un identificador, una posición en la cola y una estimación, y lo consultas o esperas el correo.
En el plan Plus el trabajo encolado se adelanta al de los planes gratuitos, que es lo que significa en la práctica la prioridad de ese plan.
Nada se convierte dos veces por dos caminos distintos
La web, la API y la conversión por correo son tres puertas a una sola canalización. Solo se diferencian en cómo se identifica a quien llama —una cookie de sesión, un token bearer o el remitente de un correo— y después ejecutan exactamente el mismo código.
Es una restricción deliberada, no un detalle de implementación. Dos implementaciones de «comprueba la cuota, husmea los bytes, protege el archivo comprimido» son la forma en que una de ellas acaba saltándose un paso justo para quienes menos probable es que lo noten.