La API de OpenAI es donde termina el marketing y empieza la ingeniería real: tokens, rate limits, costos por millón de tokens y decisiones de arquitectura que no se ven en la interfaz de ChatGPT. Esta es la guía que un equipo técnico necesita antes de escribir la primera línea de código.
Todo request a la API requiere una API key generada desde el dashboard de OpenAI, enviada como Bearer token, y opcionalmente un header de organización/proyecto si manejas múltiples equipos facturados por separado. La práctica correcta es una key por servicio/entorno (dev, staging, producción), nunca una key compartida entre todos los proyectos, para poder revocar y auditar por separado.
Durante años, Chat Completions (`/v1/chat/completions`) fue el endpoint estándar, y sigue soportado y ampliamente usado en producción. OpenAI introdujo la Responses API como el endpoint recomendado hacia adelante, que unifica capacidades que antes requerían llamadas separadas (herramientas integradas como búsqueda web, ejecución de código, y manejo de estado de conversación vía `previous_response_id` en vez de reenviar todo el historial en cada llamada).
Para proyectos nuevos, la recomendación es empezar con Responses API salvo que tengas dependencias existentes (frameworks, SDKs de terceros) que solo soporten Chat Completions — ambos coexisten y seguirán funcionando, pero las capacidades nuevas se agregan primero a Responses.
La familia de modelos incluye variantes optimizadas para distintos trade-offs de costo/latencia/calidad: los modelos "mini" (como gpt-4o-mini) para tareas de alto volumen y baja complejidad (clasificación, extracción simple), los modelos de razonamiento (familia o-series: o1, o3, o4-mini) para problemas que requieren cadenas de razonamiento largas antes de responder (matemática, código complejo, planificación), y los modelos flagship (gpt-4o, gpt-4.1 y sucesores) para el balance general.
Un error común y costoso es usar el modelo más potente para todo. En un pipeline con alto volumen de requests simples, usar un modelo mini con buen prompt engineering puede reducir el costo 10-20x sin pérdida perceptible de calidad para esa tarea específica.
Para cualquier interfaz orientada a usuario final, el streaming de tokens (Server-Sent Events) es prácticamente obligatorio: sin él, el usuario espera en silencio hasta que la respuesta completa esté lista, lo cual en respuestas largas puede sentirse como una app rota.
Los límites se miden en RPM (requests por minuto), TPM (tokens por minuto) y a veces RPD (requests por día), y escalan según el nivel de gasto acumulado de la cuenta (tiers de uso). Un sistema en producción necesita manejar el error 429 con backoff exponencial y jitter, no con reintentos inmediatos que empeoran el throttling.
El costo se factura por tokens de entrada y de salida por separado (la salida suele costar varias veces más que la entrada), y varía por modelo. El prompt caching reduce significativamente el costo cuando reutilizas el mismo prefijo largo (system prompt extenso, documentos de contexto) entre llamadas sucesivas — vale la pena estructurar los prompts para que la parte estática vaya primero y la parte variable al final, maximizando el cache hit.
Define timeouts explícitos por request, registra el `usage` de cada respuesta (tokens de entrada/salida) para monitoreo de costo real por feature, usa el parámetro `temperature` bajo (0-0.3) para tareas determinísticas y más alto para generación creativa, y nunca expongas la API key directamente al cliente/frontend — todo debe pasar por un backend propio que actúe como proxy con su propia autenticación de usuario final.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel