apis Mac & Windows

Introducción a APIs para analistas de datos

datablog apis

Actualizado: 2026-05-20

1. Qué es

Una API (Application Programming Interface) es un contrato que define cómo dos sistemas de software se comunican entre sí. No es un archivo ni un servidor — es un conjunto de reglas que establece qué se puede pedir, cómo pedirlo y qué se recibirá a cambio.

Cuando te conectas a la API de Shopify, estás enviando una petición estructurada a los servidores de Shopify siguiendo las reglas que ellos definieron. Si cumples el contrato, recibes los datos.

2. Entornos de uso (de mayor a menor volumen)

Las APIs no nacieron para que los analistas pidieran datos. Nacieron para resolver un problema de arquitectura de software: ¿cómo hace una app para que su interfaz (lo que ves) hable con sus datos (lo que no ves) sin que ambas cosas sean un solo bloque imposible de mantener?

Imagina Instagram. Cuando abres la app en tu celular, el celular no tiene acceso a la base de datos de Instagram — alguien tiene que ser el intermediario. Ese intermediario es la API. Eso pasa millones de veces por segundo, en cada app que usas.

2.1. Frontend ↔ Backend (la función principal)

Cada vez que tocas un botón en una app — abrir Instagram, hacer un pedido en Rappi, enviar un mensaje en WhatsApp — estás disparando llamadas a una API. Es la columna vertebral de todo el software moderno. El frontend (lo visual) nunca toca la base de datos. Siempre habla con la API.

2.2. Sistema A ↔ Sistema B (integraciones entre empresas)

Una tienda en Shopify recibe un pedido → automáticamente se crea una orden en el ERP → se notifica al almacén → se genera la factura en el sistema contable. Todo eso sin intervención humana. Cada flecha es una llamada de API. Es el uso más común en el mundo empresarial: conectar sistemas que antes eran islas.

2.3. APIs como producto (plataformas)

Algunas empresas construyen su negocio vendiendo acceso a su API:

Stripe: su producto es su API de pagos. No tienen app para usuarios finales.
Google Maps: cualquier app que muestra un mapa está pagando por llamadas a su API.
Twilio: envío de SMS vía API. El desarrollador paga por cada mensaje.

Aquí la API no es una pieza interna — es el producto que se vende.

2.4. Automatizaciones y workflows

Zapier, Make, n8n. Cuando dices "si llega un email con adjunto, guárdalo en Drive y avísame por Slack" — eso es una cadena de llamadas a APIs de Gmail, Drive y Slack orquestadas por una herramienta.

2.5. Extracción de datos para análisis (el caso del analista)

Es el último en la lista — no porque sea menos válido, sino porque es el menos frecuente en volumen. No es para lo que la mayoría de APIs fueron diseñadas, pero casi todas lo permiten.

Por qué el caso del analista es distinto: los primeros cuatro usos son transaccionales y en tiempo real — responden en milisegundos y lo hacen miles de veces por segundo. El uso como analista es batch y exploratorio: pides muchos datos de una vez, los almacenas y los analizas con calma. Por eso el rate limiting (límite de peticiones por minuto) duele más al analista — esa restricción existe para proteger el servidor de los casos 1 y 2. El analista es un efecto colateral bien tolerado.

3. La API desde el lado del analista

De los cinco entornos de uso, el nuestro es el último: extracción de datos para análisis. No construimos APIs ni las integramos entre sistemas — las consumimos para pedir datos, almacenarlos y analizarlos.

Eso define todo lo que sigue en este documento: cómo autenticarse, cómo hacer una petición, cómo manejar los límites que imponen las plataformas. Todo aplica a ese contexto — el analista que necesita datos que viven en un sistema externo.

3.1 . ¿A qué datos puedo acceder?

Antes de hacer cualquier petición, hay que saber si la API existe y cómo conseguir acceso. Eso depende de a quién pertenecen los datos:

1. Datos de empresa

SAP, Oracle, Azure, GCP, AWS. Los controla la organización. Necesitas que alguien interno (IT o desarrollo) te dé acceso. No puedes solicitarlo solo.

2. Datos propios

Google Workspace, Notion, GitHub. Son tuyos. Puedes generar las credenciales directamente desde el panel de la plataforma sin depender de nadie.

3. Datos de prueba

Entornos sandbox que la plataforma ofrece para desarrollo. Stripe, Salesforce Developer Edition, HubSpot. No son datos reales — sirven para aprender y probar sin consecuencias.

4. Cómo hacer una petición

Para hacer una petición a una API necesitas tres cosas en orden:

4.1. Una herramienta

No todas las APIs requieren código. Hay tres niveles:

Navegador — solo funciona con APIs públicas o las que exponen el API key en la URL (ej: Windsor.ai)
Postman — interfaz visual, sin código. Ideal para explorar una API nueva
Python con requests — desde un script, cuando ya sabes qué pedir y quieres automatizarlo

4.2. La documentación

Es el manual que te dice qué puedes pedir. Sin ella estás adivinando. Especifica los endpoints disponibles, los parámetros que acepta cada uno, cómo autenticarte y qué te devuelve.

4.3. Método de petición

No siempre es GET. Los cuatro métodos principales:

GET — pedir datos. El más común para el analista.
POST — enviar datos para crear algo nuevo. También se usa para consultas complejas cuyos parámetros no caben en la URL.
PUT/PATCH — actualizar algo existente.
DELETE — eliminar algo.

Como analistas casi siempre usamos GET, pero hay casos donde POST se usa no para crear sino para enviar parámetros de consulta complejos.

4.4. Autenticación

Antes de recibir datos, la API necesita saber quién eres. Aquí es donde entran los mecanismos — API Key y OAuth — que se cubren en la siguiente sección.

5. Autenticación

5.1. API Key

Credencial estática que el administrador genera desde la plataforma y comparte directamente por email, WhatsApp, etc. Tu script la incluye en cada petición.

Se gestiona manualmente: alguien la genera, la copia y te la pasa
Es permanente hasta que se revoque a mano — si alguien la roba, tiene acceso indefinido
Algunas plataformas permiten configurar permisos (Google, Shopify), otras no

Algunas plataformas la exponen en la URL como parámetro (ej: Windsor.ai). Es funcional pero mala práctica — la key queda visible en el historial del navegador y en los logs del servidor.

5.2. OAuth 2.0

Protocolo estándar de autorización. Siempre requiere una aplicación registrada en la plataforma — esa aplicación tiene un client_id (identificador público, siempre presente) y en algunos casos un client_secret (solo en aplicaciones de servidor, nunca en apps móviles o frontend porque no hay forma segura de guardarlo).

5.3. Otros mecanismos

Basic Auth — usuario y contraseña en cada petición. Simple, antiguo, presente en sistemas legacy.
Bearer Token — token en el header de la petición. OAuth lo usa pero también existe de forma independiente.
JWT — token con información codificada dentro. Común en APIs modernas.
HMAC — firma criptográfica de cada petición. Usado por AWS entre otros.

5.4. Diferencia clave entre API Key y OAuth 2.0

La diferencia no está en los permisos — ambos pueden tenerlos. Está en dos cosas:

Permanencia — API Key es estática hasta revocación manual. OAuth siempre genera tokens temporales que expiran.
Identidad — API Key es una credencial suelta. OAuth siempre tiene una aplicación registrada con identidad propia en la plataforma.

6. Qué devuelve una API

Cuando una petición es exitosa, la API devuelve dos cosas:

6.1. Status code

Número que indica si la petición funcionó o no. Es lo primero que mirar cuando algo falla.

Código	Significado
`200`	Éxito
`201`	Creado correctamente (respuesta a POST)
`400`	Error en tu petición — parámetro mal escrito o faltante
`401`	No estás autenticado
`403`	Autenticado pero sin permiso
`404`	El endpoint no existe
`429`	Superaste el rate limit
`500`	Error del servidor, no tuyo

6.2. Cuerpo de la respuesta

Los datos en sí. Casi siempre en formato JSON — un diccionario de clave-valor. Algunas APIs devuelven XML (más antiguo) o CSV.

7. Gotchas

Nunca compartir credenciales en el código: API Keys y tokens van en variables de entorno o archivos .env no versionados. Una credencial en un repo público es una brecha inmediata.
OAuth protege contra interceptación de credenciales, no contra acceso físico al dispositivo: si alguien tiene tu ordenador desbloqueado puede usar las sesiones activas. Son capas de seguridad distintas — OAuth resuelve una, el bloqueo de pantalla resuelve la otra.
El access_token de OAuth expira: a diferencia de una API Key, hay que manejar el refresh_token para renovarlo automáticamente.
OAuth requiere que ambas partes estén registradas en la misma plataforma: si la plataforma no conoce tu app (client_id), el flujo no puede completarse.