apis Mac & Windows

API de GitHub: cómo extraer datos públicos y privados con Postman

datablog apis

Actualizado: 2026-05-24

1. El concepto

La API de GitHub tiene dos tipos de endpoints: públicos (accesibles sin autenticación, datos visibles para cualquiera) y privados (requieren un token, devuelven datos de tu cuenta personal como emails, repos privados, notificaciones).

Como analista, esto define qué puedes extraer y cómo: para datos públicos solo necesitas la URL correcta. Para datos privados necesitas identificarte con un token.

2. Qué tipo de API es GitHub

GitHub expone una API REST. REST (Representational State Transfer) no es una tecnología — es un estilo de diseño que define cómo debe comportarse una API para ser predecible:

Cada URL representa un recurso: un usuario, un repo, un commit
El método HTTP define qué haces con ese recurso (leer, crear, modificar, borrar)
Las respuestas siempre vienen en JSON — un formato de texto estructurado legible por cualquier lenguaje de programación

La URL base de toda la API de GitHub es https://api.github.com. A partir de ahí se construyen los endpoints añadiendo el recurso:

https://api.github.com/users/{username}       → perfil de un usuario
https://api.github.com/users/{username}/repos  → repos de un usuario
https://api.github.com/user                    → tu propio perfil (autenticado)

3. Anatomía de una petición

Toda petición a una API tiene cuatro componentes. En Postman los ves visualmente — en Python los escribes en código.

3.1 Método HTTP

Define qué operación haces sobre el recurso:

Método	Acción	Ejemplo
`GET`	Leer datos	Obtener el perfil de un usuario
`POST`	Crear algo nuevo	Crear un repositorio
`PUT` / `PATCH`	Actualizar algo existente	Editar la descripción de un repo
`DELETE`	Borrar algo	Eliminar un repositorio

En este post usamos solo GET — como analista que extrae datos, es el método que más usarás.

3.2 Headers

Metadatos que viajan junto a la petición — no son los datos que pides, sino información sobre cómo hacer la petición. Se escriben como pares clave-valor.

El más importante para autenticación:

Authorization: Bearer <tu_token>

Otros headers comunes:

Header	Qué indica
`Authorization`	Quién hace la petición (token, credenciales)
`Content-Type`	En qué formato van los datos que envías (generalmente `application/json`)
`Accept`	En qué formato quieres recibir la respuesta

En Postman los headers van en la pestaña Headers. El token que configuramos en Authorization → Bearer Token es exactamente esto — Postman lo convierte en el header Authorization: Bearer <token> automáticamente.

3.3 Body

Los datos que envías junto a la petición. Solo existe en métodos que crean o modifican: POST, PUT, PATCH. Los GET no tienen body — solo pides, no envías datos.

Ejemplo de body en un POST para crear un repo:

{
  "name": "mi-nuevo-repo",
  "description": "Repositorio de prueba",
  "private": false
}

3.4 Status code

El código numérico que la API devuelve para indicar si la petición funcionó. Siempre está en la respuesta — en Postman lo ves arriba a la derecha del panel de respuesta.

Rango	Significado	Ejemplos
`2xx`	Éxito	`200 OK`, `201 Created`
`4xx`	Error del cliente	`401 Unauthorized`, `403 Forbidden`, `404 Not Found`, `429 Too Many Requests`
`5xx`	Error del servidor	`500 Internal Server Error`

Los más importantes para un analista:

401 → el token no existe, está mal escrito o expiró
403 → el token existe pero no tiene permiso para ese recurso (scope incorrecto)
404 → el endpoint o el recurso no existe
429 → superaste el rate limit — demasiadas peticiones en poco tiempo

4. Datos públicos — sin autenticación

4.1 Perfil de un usuario

Sin configurar nada en Postman — solo método y URL:

Método: GET
URL: https://api.github.com/users/{username}

Respuesta: un objeto {} con los datos públicos del perfil — nombre, ubicación, cantidad de repos públicos, fechas de creación y actualización.

Lo que no es obvio: la respuesta incluye URLs que son a su vez otros endpoints de la API:

"repos_url": "https://api.github.com/users/angelgarciadatablog/repos",
"followers_url": "https://api.github.com/users/angelgarciadatablog/followers"

Esto es una característica de las APIs REST bien diseñadas: la respuesta te dice a dónde ir después. No hay que adivinar cómo se construye la siguiente URL — la API la entrega directamente.

4.2 Repositorios públicos de un usuario

Método: GET
URL: https://api.github.com/users/{username}/repos

Respuesta: un array [] de objetos — uno por cada repo público. El campo "private": false en todos los resultados confirma que este endpoint solo devuelve repos públicos. Para ver repos privados se necesita autenticación.

Campos útiles para un analista (el resto son URLs internas de navegación):

Campo	Qué contiene
`name`	Nombre del repositorio
`language`	Lenguaje principal detectado por GitHub
`created_at`	Fecha de creación
`updated_at`	Última actualización de metadata
`pushed_at`	Último commit
`size`	Tamaño en KB
`visibility`	`public` o `private`

Diferencia clave entre endpoints: - /users/{username} → devuelve un objeto {} — un solo perfil - /users/{username}/repos → devuelve un array [] — lista de repos

Esa diferencia importa al procesar los datos en Python: un objeto se lee directamente, un array requiere iterar.

5. Datos privados — con Personal Access Token

5.1 Scopes disponibles en GitHub

Al generar un token en GitHub se piden scopes — permisos específicos que define qué puede hacer ese token. Cada scope abre acceso a un grupo de endpoints.

Los más relevantes para un analista:

Scope	Qué permite
`repo`	Leer y escribir repos privados. Incluye código, commits, issues, pull requests
`public_repo`	Solo repos públicos — sin acceso a nada privado
`read:user`	Leer el perfil completo del usuario (incluyendo email privado)
`user:email`	Leer solo el email del usuario
`notifications`	Leer notificaciones
`gist`	Crear y leer gists

Regla práctica: pedir solo el scope mínimo necesario. Si solo necesitas leer repos públicos → public_repo. Si necesitas repos privados → repo. Nunca marcar todo por comodidad.

Los scopes de GitHub son diferentes a los de otras APIs (Notion, Google, Spotify). Cada plataforma define los suyos según sus recursos.

5.2 Generar el token

GitHub → Settings (avatar arriba a la derecha)
Developer settings (al final del menú izquierdo)
Personal access tokens → Tokens (classic)
Generate new token (classic)
Note: nombre descriptivo del uso (postman-prueba-apis)
Expiration: 7 días para pruebas; en producción definir según el caso
Scope: marcar solo lo necesario — para este ejercicio: repo
Generate token — copiarlo inmediatamente, GitHub solo lo muestra una vez

5.3 Configurar el token en Postman

Nueva petición → pestaña Authorization
Type: Bearer Token
Pegar el token en el campo

Postman puede mostrar una alerta de "sensitive value" — es una advertencia de seguridad sugiriendo guardar el token como variable de entorno. Para pruebas se puede ignorar con Keep.

Lo que hace Postman internamente es agregar este header a la petición:

Authorization: Bearer <tu_token>

Una aclaración sobre el nombre: el Personal Access Token de GitHub es un Bearer Token estático — usa el header Authorization: Bearer y se genera manualmente desde la web, sin POST de login. Postman llama al campo "Bearer Token" porque ese es el formato del header. Lo que lo distingue de un Bearer Token dinámico es que es estático: no expira automáticamente y no hay que renovarlo con ninguna petición programática.

5.5 Perfil autenticado vs público

Método: GET
URL: https://api.github.com/user (sin s, sin /{username})

La diferencia con el endpoint público no siempre es visible en los datos (depende de qué hayas configurado en tu perfil), pero sí es visible en los headers de la respuesta.

5.6 Rate limiting — la diferencia más importante para un analista

En la pestaña Headers de la respuesta en Postman:

Header	Sin token	Con token
`X-RateLimit-Limit`	`60`	`5000`
`X-RateLimit-Remaining`	decrece desde 60	decrece desde 5000

60 peticiones por hora sin autenticación. 5000 con token.

Autenticarse no es solo para acceder a datos privados — es para tener 83 veces más capacidad de extracción. Sin token, cualquier script real se bloquea en minutos.

6. Más allá de Postman — extraer datos a Excel con Python

Postman sirve para explorar y entender la API. Python es donde la extracción se convierte en algo útil: un archivo Excel que puedes analizar.

6.1 Librerías necesarias

Antes de ejecutar el script hay que instalar tres librerías. En la terminal:

pip install requests pandas openpyxl

Librería	Para qué se usa
`requests`	Hacer peticiones HTTP — es el equivalente de Postman pero en código
`pandas`	Convertir el JSON en una tabla (DataFrame) y exportarla
`openpyxl`	Motor que pandas necesita para escribir archivos `.xlsx`

6.2 El script

import requests
import pandas as pd
import os

# 1. Leer el token desde una variable de entorno
token = os.environ.get("GITHUB_TOKEN")

# 2. Construir los headers — equivalente a la pestaña Authorization en Postman
headers = {
    "Authorization": f"Bearer {token}"
}

# 3. Hacer la petición GET a la API de GitHub
url = "https://api.github.com/user/repos"
response = requests.get(url, headers=headers)

# 4. Convertir la respuesta JSON en una lista de diccionarios Python
repos = response.json()

# 5. Convertir la lista en una tabla (DataFrame)
df = pd.DataFrame(repos)

# 6. Quedarse solo con los campos útiles
columnas = ["name", "language", "created_at", "updated_at", "pushed_at", "size", "visibility"]
df = df[columnas]

# 7. Exportar a Excel
df.to_excel("repos_github.xlsx", index=False)
print(f"Exportados {len(df)} repositorios")

6.3 Qué hace cada línea

Línea 1-3 — import Cargar las librerías instaladas. Python no las carga automáticamente — hay que pedirlas explícitamente al inicio del script.

Línea 5-6 — os.environ.get("GITHUB_TOKEN") Leer el token desde las variables de entorno del sistema, no desde el código. Si el token estuviera escrito directo en el script y subieras ese archivo a GitHub, cualquiera podría verlo. Las variables de entorno son la forma estándar de manejar credenciales.

Para configurar la variable en Mac, antes de ejecutar el script:

export GITHUB_TOKEN="pega_tu_token_aqui"

Línea 8-10 — headers Un diccionario Python con los mismos headers que configuraste en Postman. f"Bearer {token}" inserta el valor de la variable token dentro del texto.

Línea 12-14 — requests.get() La petición GET a la API. response guarda todo lo que devuelve el servidor: los datos, el status code, los headers de respuesta.

Línea 16 — .json() Convierte el texto JSON de la respuesta en una estructura Python. Dado que el endpoint de repos devuelve un array [], el resultado es una lista de diccionarios — uno por cada repo.

Línea 18 — pd.DataFrame(repos) Convierte esa lista de diccionarios en una tabla. pandas infiere automáticamente que cada diccionario es una fila y cada clave es una columna.

Línea 20-21 — df[columnas] Filtrar solo las columnas que interesan. La respuesta de GitHub tiene más de 80 campos por repo — la mayoría son URLs internas que no sirven para análisis.

Línea 23-24 — .to_excel() Exportar el DataFrame como archivo Excel en la carpeta donde se ejecuta el script. index=False evita que pandas agregue una columna extra de números al inicio.

6.4 Qué pasa internamente

Script Python
    → requests.get() construye la petición HTTP
    → La envía a api.github.com
    → GitHub valida el token y devuelve el JSON
    → .json() lo convierte en lista Python
    → pd.DataFrame() lo convierte en tabla
    → .to_excel() lo escribe en disco

Es el mismo flujo que hiciste en Postman — pero automatizado y con el resultado en un archivo que puedes abrir en Excel.

6.5 Destinos de los datos

El script en este post exporta a Excel, pero Excel es solo un destino de exploración. Hay tres opciones reales según el contexto:

Opción 1 — Python → CSV → Power BI El script guarda los datos en un CSV. Power BI lee ese archivo. Simple y sin intermediarios. El problema: cada vez que quieres datos frescos hay que re-ejecutar el script manualmente.

Opción 2 — Power Query M directo en Power BI Power BI tiene su propio lenguaje de transformación (M) que puede llamar APIs con headers personalizados, sin Python. Todo ocurre dentro de Power BI. El problema: el token queda guardado dentro del archivo, lo que representa un riesgo de seguridad si el archivo se comparte.

Opción 3 — Python → Base de datos → Power BI El script carga los datos en una base de datos. Power BI se conecta a la base de datos. Es el enfoque profesional: datos siempre disponibles, actualizables de forma programada, sin exponer el token en ningún archivo. Requiere tener una base de datos configurada.

Para empezar: Opción 1. Cuando haya más contexto de bases de datos, la Opción 3 es el camino natural.

Nota: no es posible conectar este endpoint directamente con el "Conectar web" de Power BI. Ese conector está pensado para HTML o fuentes simples, no para JSON autenticado que requiere enviar un Bearer Token en los headers.

7. Mi conclusión

La API de GitHub es REST, devuelve JSON y usa Personal Access Token (un Bearer Token estático) para autenticación — tres conceptos que se repiten en la mayoría de APIs modernas. Lo específico de GitHub son sus endpoints y sus scopes.

El flujo que cubre este post — explorar en Postman, autenticarse con token, extraer con Python, exportar a Excel — es el mismo que aplica para cualquier otra API. Lo que cambia entre una API y otra es dónde generas el token, qué scopes existen y cómo están organizados los endpoints. La estructura de fondo es siempre la misma.

En este post solo usamos los endpoints de usuarios y repositorios. GitHub tiene muchos más — issues, pull requests, commits, organizaciones, entre otros — pero eso lo exploraremos cuando profundicemos más en GitHub.

8. Recursos

Pendientes

(sección interna — se elimina antes de publicar) - [ ] Grabar video siguiendo los pasos documentados - [ ] Revisar que todos los endpoints siguen activos antes de publicar - [ ] Agregar caso equivalente con Notion API (post separado)