Tu equipo de desarrollo te dice "esto lo exponemos como API" o "corré este comando de CLI" en la misma reunión, y vos asentís sin tener muy claro qué significa ninguna de las dos cosas. No es humillante no saberlo — son términos que se usan todo el tiempo puertas adentro de un equipo técnico y casi nunca se explican puertas afuera.
La buena noticia es que la diferencia no es complicada una vez que la sacás del inglés técnico. Ambas son formas de "usar" un programa, pero pensadas para audiencias completamente distintas: una es para que un humano (o un script) escriba comandos, la otra es para que dos programas se hablen entre sí sin que nadie esté tipeando en el medio. Entender cuál necesitás vos, como founder, tiene impacto directo en cuánto cuesta construir tu producto y qué tan rápido lo podés lanzar.
Qué es una CLI, en criollo
"CLI" son las siglas de "command-line interface", interfaz de línea de comandos. En criollo: es una herramienta que se usa escribiendo instrucciones de texto en una terminal — esa pantalla oscura con letras que seguramente viste de reojo en la compu de algún developer.
Ejemplo real: cuando un developer sube un cambio de código a producción, no hace click en ningún botón — escribe algo como git push o vercel deploy y presiona Enter. Esa es una CLI en acción: la usa un humano, o un script que imita a un humano, para algo puntual y rápido, sin pantalla bonita alrededor.
Una CLI es barata de construir porque no tiene interfaz visual que diseñar: no hay botones, ni pantallas, ni estados de carga — es texto que entra y texto que sale. Por eso muchas herramientas internas (scripts de un equipo, utilidades para el propio developer) arrancan como CLI y nunca necesitan ser otra cosa.
Qué es una API, en criollo
"API" son las siglas de "application programming interface". En criollo: es una forma de que DOS PROGRAMAS se hablen entre sí, sin que haya un humano tipeando en el medio. Tu app le pide algo a otra app —o a otra parte de sí misma que corre en otro servidor—, esa otra app responde con datos, y ninguna persona ve ese intercambio en tiempo real.
Ejemplo real: cuando tu e-commerce cobra una tarjeta de crédito, tu código le manda una solicitud a la API de Stripe con el monto y los datos de la tarjeta. Stripe procesa el cobro y le devuelve una respuesta a tu código diciendo si funcionó o no. Vos, como usuario final del checkout, ves solo un cartel de "pago aprobado" — todo el diálogo entre programas pasó por atrás, en milisegundos.
Una API necesita más trabajo que una CLI: hay que pensar en seguridad (quién puede llamarla y con qué credenciales), en versionado (qué pasa cuando la cambiás y otros sistemas ya dependen de la versión vieja) y en documentación, para que otros equipos —a veces de otras empresas— sepan usarla sin llamarte por teléfono. Es una promesa pública de que "esto va a seguir funcionando así", y sostenerla cuesta tiempo y plata.
La comparación de un vistazo
| CLI | API | |
|---|---|---|
| Quién la usa | Un humano en su terminal, o un script | Otro programa u otro sistema |
| Para qué sirve | Ejecutar una acción puntual, rápido | Que dos sistemas se conecten automáticamente |
| Ejemplo real | git push, vercel deploy, el comando stripe listen | La API de Stripe cobrando una tarjeta desde tu checkout |
| Costo de construir | Bajo — no hay interfaz visual que diseñar | Medio a alto — seguridad, versionado, documentación |
| Quién depende de que siga funcionando igual | El mismo equipo que la usa | Terceros externos que integraron su sistema con el tuyo |
Por qué a veces una herramienta tiene las dos cosas
Muchas herramientas serias tienen API y CLI al mismo tiempo, porque resuelven necesidades distintas dentro de la misma audiencia técnica. El ejemplo más claro es Stripe: tiene una API para que tu aplicación cobre tarjetas en producción, con clientes y plata reales de por medio. Pero también tiene una CLI (el comando stripe) que un developer instala en su compu para probar cosas rápido desde la terminal —simular un webhook, ver logs de un pago en tiempo real— sin escribir código nuevo cada vez que quiere chequear algo.
Otro caso conocido: Vercel, donde desplegamos buena parte de lo que construimos, tiene un dashboard visual, una API para integrarse con otros sistemas y una CLI (vercel deploy, vercel env) que el equipo usa a diario porque es más rápido que abrir el navegador. Ninguna de las tres reemplaza a la otra: cada una es para un momento y una audiencia distinta dentro del mismo producto.
Cuándo como founder te tiene que importar la diferencia
Acá está la parte que te toca decidir a vos, no solo al equipo técnico, porque tiene impacto directo en presupuesto y en plazos:
- Si tu producto necesita que OTROS sistemas se conecten con él de forma automática —un cliente que quiere integrar tu herramienta con su CRM, un partner que necesita mandarte datos en tiempo real, una app de terceros que va a construir sobre tu plataforma— necesitás una API. No hay atajo: sin API esa integración no existe, por más prolija que sea tu CLI.
- Si lo que necesitás es una herramienta interna que usa tu propio equipo a mano —generar un reporte, correr una migración de datos, automatizar una tarea repetitiva de operaciones— una CLI puede alcanzar de sobra, y sale sensiblemente más barata y más rápida de construir que una API completa.
El error común, y caro, es pedir una API "por las dudas", cuando en realidad todavía nadie externo la va a llamar. Ahí estás pagando seguridad, documentación y versionado que no necesitás hoy. El error opuesto, menos frecuente pero también costoso, es quedarte con una CLI cuando un cliente real ya está pidiendo integrarse: ahí la CLI se vuelve un cuello de botella que frena una venta.
Cómo lo resolvemos en Cambalache
Cuando armamos una automatización interna, para un cliente o para nosotros mismos, arrancamos casi siempre por CLI: es la forma más rápida de probar que la lógica funciona, sin gastar tiempo todavía en seguridad externa o documentación pública. Recién exponemos esa misma lógica como API cuando aparece una necesidad concreta —un cliente cuyo propio sistema necesita conectarse automáticamente con lo que construimos. Ese orden, CLI primero y API después solo si hace falta, evita construir infraestructura que nadie va a usar y deja el presupuesto del cliente para lo que sí mueve la aguja del negocio.
Si en algún momento tu equipo menciona un "MCP" en la misma conversación, es un concepto relacionado pero distinto: una forma estandarizada de conectar asistentes de IA con APIs y herramientas ya existentes. Vale la pena entender qué es un MCP si estás evaluando meterle IA a tus propias integraciones.
Conclusión
CLI y API no son dos tecnologías compitiendo por el mismo trabajo: son dos formas distintas de usar un programa, para audiencias distintas. Una para que un humano escriba comandos, la otra para que dos sistemas se hablen sin que nadie esté mirando. La pregunta que te toca hacerte como founder no es cuál es "mejor", sino quién va a usar esa pieza de tu producto. Si la respuesta es "otro sistema, de forma automática", necesitás una API y hay que presupuestarla como tal; si la respuesta es "mi propio equipo, a mano", una CLI resuelve el problema por una fracción del costo. Si además estás definiendo qué proveedor de IA va a correr detrás de esas integraciones, Claude vs OpenAI compara las dos APIs que más elegimos hoy para eso.