Chuleta de curl: 40+ ejemplos de comandos HTTP y API

Llevas tres saltos SSH dentro de una máquina de staging, una API devuelve algo que no cuadra y el único cliente HTTP instalado es curl. O estás leyendo un script de CI que hace un health-check de un servicio y quieres saber qué hace de verdad -fsS. O un compañero pegó un one-liner en Slack y te toca adaptarlo. curl está en todas partes, y sus flags son tan parcas que nadie se las sabe todas.

Esta chuleta de curl está hecha justo para esos momentos. Arriba tienes una tabla de referencia rápida con la docena de flags que usas a diario, y debajo hay ejemplos listos para copiar y pegar para cada tarea habitual: peticiones GET y POST, envío de cabeceras, auth con token Bearer, subida y descarga de archivos y pruebas de API en scripts. Cada comando usa una URL real y ejecutable (httpbin.org o un marcador api.example.com), así que puedes pegarlo y comprobarlo tú mismo. El comportamiento sigue lo que dice la documentación oficial de curl y el RFC 9110, el estándar actual de semántica HTTP.

Referencia rápida: las flags de curl que de verdad usarás

El noventa por ciento del curl diario cabe en una docena de flags. Guarda esta tabla en marcadores; el resto de la guía las amplía con ejemplos ejecutables.

Flag	Significado	Ejemplo
`-X`	Definir el método HTTP	`curl -X DELETE https://api.example.com/items/42`
`-H`	Añadir una cabecera de petición (repetible)	`curl -H "Accept: application/json" https://httpbin.org/get`
`-d`	Enviar un cuerpo de petición (implica POST)	`curl -d "name=alice" https://httpbin.org/post`
`--json`	Enviar un cuerpo JSON + fijar las cabeceras JSON	`curl --json '{"id":1}' https://httpbin.org/post`
`-F`	Enviar un campo de formulario / archivo multipart	`curl -F "file=@report.pdf" https://httpbin.org/post`
`-o`	Guardar la salida en un archivo con nombre	`curl -o page.html https://example.com`
`-O`	Guardar usando el nombre de archivo remoto	`curl -O https://example.com/archive.zip`
`-L`	Seguir redirecciones	`curl -L https://httpbin.org/redirect/2`
`-u`	Auth básica `user:pass`	`curl -u alice:s3cret https://httpbin.org/basic-auth/alice/s3cret`
`-i`	Incluir las cabeceras de respuesta en la salida	`curl -i https://httpbin.org/get`
`-I`	Obtener solo las cabeceras (HEAD)	`curl -I https://example.com`
`-v`	Verboso: muestra la petición + el handshake TLS	`curl -v https://example.com`
`-s`	Silencioso (sin medidor de progreso)	`curl -s https://httpbin.org/get`
`-w`	Escribir variables tras la transferencia	`curl -s -o /dev/null -w "%{http_code}" https://example.com`
`-b`	Enviar cookies (cadena o archivo)	`curl -b cookies.txt https://httpbin.org/cookies`
`-c`	Guardar las cookies recibidas en un jar	`curl -c cookies.txt https://httpbin.org/cookies/set/a/1`
`-k`	Omitir la verificación del certificado TLS	`curl -k https://self-signed.example.com`
`--http2`	Solicitar HTTP/2	`curl --http2 https://example.com`
`--http3`	Solicitar HTTP/3 (QUIC)	`curl --http3 https://example.com`
`-T`	Subir un archivo con PUT	`curl -T backup.tar https://api.example.com/files/backup.tar`
`--data-urlencode`	Codificar en URL un campo del cuerpo	`curl --data-urlencode "q=hello world" https://httpbin.org/get -G`
`--max-time`	Limita la duración total de la transferencia (segundos)	`curl --max-time 10 https://example.com`
`--connect-timeout`	Limita el establecimiento de la conexión (segundos)	`curl --connect-timeout 5 https://example.com`
`--retry`	Reintenta N veces una transferencia fallida	`curl --retry 3 https://example.com`
`--limit-rate`	Limita el ancho de banda de la transferencia	`curl --limit-rate 2M -O https://example.com/big.iso`

Fundamentos de la sintaxis de curl: anatomía de una petición

Un comando curl es el binario, algunas flags y una URL. La URL puede ir antes o después de las flags; a curl le da igual el orden. Lo que sí le importa es qué flags implican un método o un cuerpo, porque ahí es donde unas afectan a otras.

Una petición GET simple

Sin flag de método, curl envía un GET. Este es el comando completo:

curl https://httpbin.org/get

httpbin te devuelve tu propia petición como JSON, así que va de perlas para hacer pruebas. Añade una cadena de consulta igual que lo harías en un navegador:

curl "https://httpbin.org/get?page=2&sort=desc"

Pon la URL entre comillas. Un & suelto le indica a tu shell que lance el comando en segundo plano y se traga en silencio todo lo que viene después. Es uno de los errores más comunes con curl, y lo retomo en la sección de tropiezos más abajo.

Ver la respuesta: cuerpo, cabeceras, ambos

Por defecto curl imprime solo el cuerpo de la respuesta. Tres flags cambian lo que ves:

# Cuerpo + línea de estado + cabeceras de respuesta
curl -i https://httpbin.org/get

# Solo cabeceras — envía una petición HEAD, sin cuerpo
curl -I https://example.com

# Traza completa: línea de petición, cabeceras de petición, handshake TLS, respuesta
curl -v https://example.com

Usa -i cuando quieras el cuerpo y, de paso, un vistazo a Content-Type o a un Set-Cookie. Usa -I para inspeccionar un recurso sin descargarlo (tamaño del archivo, última modificación, destino de la redirección). Y tira de -v cuando algo falla y necesitas ver exactamente qué envió curl.

Seguir redirecciones

curl no sigue redirecciones a menos que se lo pidas. Accede a una URL que devuelve 301 o 302 sin -L y obtendrás la propia respuesta de redirección, no el destino:

# Se detiene en el 302, no imprime nada útil
curl https://httpbin.org/redirect/1

# Sigue la cadena hasta el 200 final
curl -L https://httpbin.org/redirect/1

Si no tienes claro por qué una petición acaba donde acaba, -IL muestra el código de estado de cada salto. Para saber qué significa cada uno de esos códigos, y por qué 301 y 302 no son intercambiables, consulta la chuleta de códigos de estado HTTP.

Métodos HTTP con curl (GET, POST, PUT, PATCH, DELETE)

curl elige el método solo según tus flags: -d o --json implican POST, y una URL a secas implica GET. Usa -X únicamente cuando necesites un método que no encaje con el cuerpo que estás enviando.

GET con parámetros de consulta

Montar una cadena de consulta a mano se tuerce en cuanto los valores llevan espacios o &. La flag -G le dice a curl que pegue los campos de --data-urlencode a la URL como una cadena de consulta bien codificada:

curl -G https://httpbin.org/get \
  --data-urlencode "q=hello world" \
  --data-urlencode "tag=c++"

Esto produce ?q=hello%20world&tag=c%2B%2B: curl se encarga de la codificación porcentual para que no acabes mandando una URL rota.

POST: datos de formulario vs JSON

Una curl post request se hace de dos maneras habituales. Codificada como formulario (el clásico cuerpo de formulario HTML):

curl -d "name=alice&role=admin" https://httpbin.org/post

-d fija Content-Type: application/x-www-form-urlencoded y cambia el método a POST por ti. Para una API JSON, envía JSON en su lugar:

curl -d '{"name":"alice","role":"admin"}' \
  -H "Content-Type: application/json" \
  https://httpbin.org/post

Hay una forma más limpia de hacerlo, que veremos en la siguiente sección.

PUT y PATCH

PUT reemplaza un recurso; PATCH actualiza una parte de él. PUT es idempotente: enviarlo dos veces deja el mismo estado.

# Reemplaza el recurso completo
curl -X PUT -d '{"name":"alice","role":"owner"}' \
  -H "Content-Type: application/json" \
  https://api.example.com/users/7

# Actualiza un solo campo
curl -X PATCH -d '{"role":"owner"}' \
  -H "Content-Type: application/json" \
  https://api.example.com/users/7

DELETE

DELETE normalmente no lleva cuerpo, así que -X es todo lo que necesitas:

curl -X DELETE https://api.example.com/users/7

Envío de cabeceras y cuerpos JSON

La mayor parte del trabajo real con API se reduce a cabeceras y JSON. Dos flags cargan con casi todo: -H y --json.

Cabeceras curl personalizadas con `-H`

-H añade una cabecera y se puede repetir tantas veces como haga falta. Así es como fijas Accept, Authorization, cabeceras X- propias e IDs de petición:

curl https://httpbin.org/headers \
  -H "Accept: application/json" \
  -H "X-Request-Id: 9f3c1a" \
  -H "User-Agent: my-cli/1.0"

Para eliminar una cabecera por defecto que curl enviaría de otro modo, dale un valor vacío (-H "User-Agent:"). Para enviar una cabecera sin valor, usa un punto y coma (-H "X-Empty;").

POST JSON: `-d` vs la flag moderna `--json`

Desde curl 7.82, --json es la forma idiomática de enviar una curl post request con JSON. Se ocupa de tres cosas de golpe: fija Content-Type: application/json, fija Accept: application/json y manda el cuerpo tal cual.

# La forma antigua y verbosa — tres piezas que mantener sincronizadas
curl -X POST \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{"name":"alice"}' \
  https://httpbin.org/post

# Equivalente moderno
curl --json '{"name":"alice"}' https://httpbin.org/post

--json es repetible y concatena lo que le pases, y --json @file.json lee el cuerpo desde un archivo. Tenlo como primera opción para cualquier API JSON.

Content-Type y Accept

De estas dos cabeceras salen los errores 415 y 406. Content-Type describe el cuerpo que envías; Accept dice qué quieres recibir. Manda JSON a un endpoint que solo acepta datos de formulario y te llevarás un 415 Unsupported Media Type. Pide XML a una API que solo da JSON y puede que recibas 406 Not Acceptable. (Esos códigos se desglosan en la guía de códigos de estado HTTP.)

Cuando la respuesta llega como un muro de JSON minificado, ponlo legible con el Formateador JSON o pásalo directamente por jq para sacar un campo:

curl -s https://httpbin.org/json | jq '.slideshow.title'

Para el repertorio completo de filtros de jq (seleccionar, mapear y reestructurar respuestas de API), consulta la chuleta de jq para JSON en la línea de comandos.

Autenticación con curl

Con cuatro estilos de auth cubres casi cualquier API: auth básica, tokens Bearer, claves de API y cookies.

Auth básica (`-u user:pass`)

-u envía una cabecera HTTP Authorization: Basic con tus credenciales codificadas en Base64:

curl -u alice:s3cret https://httpbin.org/basic-auth/alice/s3cret

Omite la contraseña (-u alice) y curl te la pedirá por teclado, así no queda en el historial de tu shell.

Tokens Bearer y OAuth

La mayoría de las API modernas usan un curl bearer token: un token de acceso OAuth 2.0 o un token de API en la cabecera Authorization. curl trae un atajo, --oauth2-bearer, que hace lo mismo que escribir la cabecera a mano:

# Cabecera explícita
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.abc" \
  https://api.example.com/me

# Atajo
curl --oauth2-bearer "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.abc" \
  https://api.example.com/me

Si el backend rechaza el token, decodifícalo con el Decodificador JWT y revisa los claims exp (expiración), aud (audiencia) e iss (emisor) antes de echarle la culpa a curl. Lo normal es que el problema sea un token caducado o con la audiencia equivocada.

Claves de API (cabecera vs parámetro de consulta)

Unas API quieren la clave en una cabecera, otras en un parámetro de consulta. Las cabeceras son más seguras, porque las URL se acaban colando en los logs y en el historial del navegador:

# Preferido: la clave en una cabecera
curl -H "X-API-Key: sk_live_a1b2c3" https://api.example.com/data

# Menos seguro: la clave en la URL (acaba en los logs de acceso)
curl "https://api.example.com/data?api_key=sk_live_a1b2c3"

Cookies (`-b` para enviar, `-c` para guardar)

-c escribe un jar de cookies; -b lo vuelve a leer. Así es como mantienes una sesión viva a lo largo de varias peticiones:

# Inicia sesión y guarda la cookie de sesión
curl -c jar.txt -d "user=alice&pass=s3cret" https://httpbin.org/cookies/set/session/abc123

# Reutilízala en la siguiente llamada
curl -b jar.txt https://httpbin.org/cookies

Nota de seguridad: los tokens y las credenciales solo deben viajar por HTTPS, porque TLS cifra las cabeceras y el HTTP plano no. Evita poner secretos directamente en la línea de comandos, donde acaban en el historial de tu shell y en la salida de ps. Lee la cabecera desde un archivo con -H @authfile o saca el valor de una variable de entorno (-H "Authorization: Bearer $TOKEN").

Descarga y subida de archivos

curl se llamó “client URL” porque mover archivos fue su trabajo original. Tanto las descargas como las subidas tienen un par de flags que conviene tener fichadas.

Descarga: `-O` vs `-o` vs `-C -`

-O (O mayúscula) guarda el archivo con su nombre remoto. -o (minúscula) te deja poner el nombre que quieras. -C - reanuda una descarga a medias desde donde se cortó:

# Guarda con el nombre de archivo remoto: archive.zip
curl -O https://example.com/downloads/archive.zip

# Guarda con un nombre que tú eliges
curl -o backup.zip https://example.com/downloads/archive.zip

# Reanuda una descarga interrumpida
curl -C - -O https://example.com/downloads/archive.zip

# Sigue las redirecciones hasta el archivo real (común con CDN)
curl -OL https://example.com/latest/archive.zip

Para descargar contenido (curl download file) que está detrás de una redirección, añade -L: las páginas de releases y los enlaces de CDN casi siempre redirigen.

Subida: `-T` vs `-F`

-T sube un archivo con PUT y manda los bytes en bruto como cuerpo (lo típico para almacenamiento de objetos y endpoints REST de archivos). -F envía una petición multipart/form-data, el mismo formato que usa un navegador para los campos de archivo:

# PUT de bytes en bruto
curl -T report.pdf https://api.example.com/files/report.pdf

# Subida multipart/form-data (fíjate en el prefijo @)
curl -F "file=@report.pdf" -F "title=Q2 report" https://httpbin.org/post

El prefijo @ le dice a curl que lea el contenido del archivo. Sin él, -F "file=report.pdf" manda la cadena literal report.pdf, no el archivo.

`--data-urlencode` y la codificación porcentual

Cuando un valor lleva espacios, &, = o caracteres no ASCII, -d lo manda tal cual y te rompe la petición. --data-urlencode lo codifica como toca:

# Mal: el & parte el cuerpo, el espacio es inválido
curl -d "q=hello world&filter=a&b" https://httpbin.org/post

# Bien: cada campo se codifica porcentualmente
curl --data-urlencode "q=hello world" \
  --data-urlencode "filter=a&b" \
  https://httpbin.org/post

Si necesitas entender qué significan esas secuencias %20 y %26, o depurar un valor que está doblemente codificado, pégalo en el Decodificador y Codificador URL o lee el recorrido a nivel de bytes en la guía de codificación y decodificación de URL.

Pruebas de API e inspección de respuestas

curl da lo mejor de sí en scripts y en CI: -w saca a la luz todo sobre la transferencia y los códigos de salida hacen que los fallos se detecten solos.

Solo el código de estado

Para obtener únicamente el estado HTTP, descarta el cuerpo con -o /dev/null e imprime el código con -w:

curl -s -o /dev/null -w "%{http_code}\n" https://httpbin.org/status/204
# → 204

En esto se basa cualquier health-check de curl api testing. Para interpretar el número que te llega, la chuleta de códigos de estado HTTP cubre todos los rangos.

Desglose de tiempos

-w expone variables de tiempo, así que puedes ver dónde se va: DNS, conexión TCP, TLS o el propio servidor:

curl -s -o /dev/null \
  -w "dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s total=%{time_total}s\n" \
  https://example.com
# → dns=0.004s connect=0.021s tls=0.058s total=0.142s

Un time_appconnect alto apunta a TLS, un time_starttransfer alto apunta a un backend lento.

Silencioso pero mostrando errores

-s oculta el medidor de progreso, pero de paso también oculta los mensajes de error, y ahí es donde te la juega en los scripts. Combínalo con -S para que curl se calle cuando todo va bien y siga avisando de los fallos:

curl -sS https://api.example.com/health

curl en CI / scripts: fallar ante errores HTTP

Por defecto curl sale con 0 incluso ante un 404 o un 500, porque la transferencia en sí salió bien. En un health-check eso es justo lo contrario de lo que quieres. -f (fail) hace que curl salga con un valor distinto de cero ante errores HTTP, para que tu pipeline se entere:

# Hace fallar el build si el endpoint devuelve 4xx/5xx
curl -fsS https://api.example.com/health || exit 1

-fsS (fail, silent, show-errors) es la combinación de toda la vida para health-checks. Si quieres un diagnóstico más completo, --fail-with-body (curl 7.76+) imprime la respuesta de error antes de salir.

Tiempos de espera y reintentos

Un health check que se queda colgado para siempre es peor que uno que falla rápido. Acota cada petición en script con --max-time (tope para toda la transferencia) y --connect-timeout (tope solo para establecer la conexión):

# Se rinde tras 5 s de conexión, 10 s en total
curl --connect-timeout 5 --max-time 10 -fsS https://api.example.com/health

En una red inestable, --retry reintenta una transferencia fallida con retroceso exponencial. Por defecto solo reintenta fallos transitorios (tiempos agotados, 5xx); agrega --retry-all-errors para reintentar también las conexiones rechazadas:

# Hasta 3 intentos, con una pausa creciente entre ellos
curl --retry 3 --retry-all-errors --max-time 30 -fsS https://api.example.com/health

Cuando un script descarga un archivo grande y no quieres saturar el enlace, --limit-rate limita el ancho de banda: --limit-rate 2M lo mantiene en 2 MB/s.

HTTP/1.1, HTTP/2 y HTTP/3 con curl

curl negocia la versión de HTTP sobre TLS mediante ALPN. Puedes forzar una versión concreta cuando necesites probar una ruta de protocolo en particular.

`--http2` y `--http3`

# Solicita HTTP/2 (cae a 1.1 si no está disponible)
curl --http2 https://example.com

# Solicita HTTP/3 sobre QUIC
curl --http3 https://example.com

HTTP/3 corre sobre QUIC y requiere TLS 1.3. Solo funciona si tu curl se compiló con un backend compatible con HTTP/3 y el servidor lo anuncia con una cabecera Alt-Svc. Lanza curl --version para confirmar que HTTP3 aparece en la línea de features; si no está, --http3 dará error.

Información verbosa de TLS / ALPN

-v muestra el protocolo negociado y el handshake TLS, que es como compruebas que la versión que pediste tuvo efecto de verdad:

curl -v --http2 https://example.com 2>&1 | grep -i "ALPN\|HTTP/2"
# → * ALPN: server accepted h2
# → > GET / HTTP/2

Busca ALPN: server accepted h2 (HTTP/2) o h3 (HTTP/3) en la salida del handshake.

8 tropiezos comunes con curl (y cómo resolverlos)

Estos ocho terminan pillando a todo el mundo tarde o temprano.

Comillas simples vs dobles. Las comillas dobles dejan que el shell expanda $VARS; las simples pasan todo al pie de la letra. Usa comillas simples para los cuerpos JSON, así $ y ! no se interpretan: curl --json '{"price":"$5"}'. Usa comillas dobles cuando quieras esa expansión: -H "Authorization: Bearer $TOKEN".
-d no codifica en URL. Un espacio o un & dentro de un valor de -d corrompe el cuerpo. Pásate a --data-urlencode para cualquier valor que no venga ya codificado.
-X POST redundante con -d. -d ya implica POST. Escribir -X POST -d ... es inofensivo pero sobra; y lo que es peor, -X GET -d ... envía un cuerpo con un GET, cosa que descoloca a algunos servidores. Deja que la flag del cuerpo fije el método.
Olvidarse del @ al leer desde un archivo. -d @body.json lee el archivo; -d body.json envía el texto literal body.json. La misma trampa cae con -F "file=@upload.png" frente a -F "file=upload.png".
Tirar de -k ante errores de certificado. -k desactiva la verificación TLS y tapa problemas reales (un certificado caducado, un hostname que no coincide, un intermediario que falta). Ataca la causa raíz: instala la CA con --cacert ca.pem o actualiza el almacén de confianza de tu sistema. Reserva -k para un servidor de desarrollo autofirmado que controles tú por completo.
-s tragándose los errores. El modo silencioso esconde los fallos en los scripts. Usa siempre -sS para que los errores sigan saliendo a la luz.
[ ] { } en las URL expandidos por el globbing. curl trata [1-5] y {a,b} como rangos o listas de URL. Una URL con corchetes literales (algo habitual en parámetros de consulta de tipo array como arr[]=1) acaba hecha trizas. Desactiva el globbing con -g: curl -g "https://api.example.com/items?id[]=1&id[]=2".
Mayúsculas y duplicados en las cabeceras. Los nombres de las cabeceras HTTP no distinguen mayúsculas de minúsculas, pero enviar la misma cabecera dos veces suele enviarlas las dos, y cada servidor reacciona a su manera: unos se quedan con la primera, otros con la última y otros la rechazan. Si sobrescribes una por defecto como User-Agent, fíjala una sola vez con -H en vez de fiarte del orden.

curl vs wget vs HTTPie: cuál usar

Las tres descargan sobre HTTP, pero cada una está pensada para un trabajo distinto. Aquí tienes la decisión curl vs wget (con HTTPie de propina) de un vistazo:

Tarea	curl	wget	HTTPie
Llamada/depuración rápida de API	Excelente	Limitado	Excelente
Cuerpos JSON	Bueno (`--json`)	Incómodo	Excelente (nativo)
Descarga/réplica recursiva de un sitio	No	Excelente (`-r`)	No
Reanudar + reintentar descargas grandes	Bueno (`-C -`)	Excelente (incorporado)	No
Scripting / CI (códigos de salida, `-w`)	Excelente	Bueno	Bueno
Salida bonita y coloreada por defecto	No	No	Excelente
Preinstalado en casi todas partes	Sí	A menudo	Rara vez

En resumen: tira de curl para depurar API y para scripts (está en todas partes y -w no tiene rival), de HTTPie cuando quieras una ergonomía JSON legible en tu propia máquina, y de wget para replicar sitios o descargar archivos en lote con reintentos automáticos.

Preguntas frecuentes

¿Para qué se usa curl?

curl es una herramienta de línea de comandos para transferir datos hacia y desde un servidor sobre HTTP, HTTPS, FTP y muchos otros protocolos. Los desarrolladores lo usan para llamar y depurar API, mover archivos en ambos sentidos y lanzar health-checks en scripts y pipelines de CI.

¿Cómo envío una petición POST con curl?

Usa -d para datos de formulario o --json para JSON: curl --json '{"name":"alice"}' https://httpbin.org/post. Las dos flags ponen el método en POST por su cuenta, así que no hace falta -X POST.

¿Cómo añado una cabecera en curl?

Usa -H "Name: value" y repítelo para varias cabeceras: curl -H "Accept: application/json" -H "X-Request-Id: 9f3c1a" https://httpbin.org/headers. No hay tope en cuántas veces puedes pasar -H.

¿Cómo envío un token Bearer con curl?

Pasa una cabecera Authorization: curl -H "Authorization: Bearer YOUR_TOKEN" https://api.example.com/me, o tira del atajo --oauth2-bearer YOUR_TOKEN. Envía tokens solo por HTTPS y decodifícalos con el Decodificador JWT cuando estés depurando.

¿Cómo descargo un archivo con curl?

Usa -O para conservar el nombre de archivo remoto o -o name para ponerle el tuyo: curl -O https://example.com/archive.zip. Añade -L para seguir redirecciones y -C - para reanudar una descarga que se cortó.

¿Cómo veo solo el código de estado HTTP con curl?

Descarta el cuerpo e imprime el código: curl -s -o /dev/null -w "%{http_code}" https://example.com. Este es el patrón estándar para los health-checks en scripts.

¿Cuál es la diferencia entre curl y wget?

curl transfiere un único recurso y escribe en stdout por defecto, así que va de maravilla para llamadas de API y scripting. wget se especializa en descargar, con réplica recursiva y reintentos automáticos incluidos. Para pruebas de API, usa curl; para descargas masivas de archivos, usa wget.

¿Está curl disponible en Windows?

Sí. curl viene con Windows 10 (build 1803+) y Windows 11, disponible como curl tanto en el Símbolo del sistema como en PowerShell. Eso sí, PowerShell tuvo durante años a curl como alias de Invoke-WebRequest, así que llama a curl.exe de forma explícita si las flags se comportan de manera rara.

Para terminar

curl premia un poquito de memoria: la tabla de flags del principio cubre la inmensa mayoría de lo que vas a escribir, y lo demás se reduce a saber qué flags implican un método, cuáles piden comillas y cuáles te mienten en los scripts (sí, hablo de ti, -s a secas). Deja esta chuleta de curl abierta al lado de tu terminal. Si prefieres armar los comandos de forma interactiva, prueba nuestro generador de comandos cURL para crearlos visualmente.

Los siguientes pasos en un flujo de trabajo con API están a un clic. Lanza la petición con curl, descifra lo que te devuelve con la chuleta de códigos de estado HTTP y luego deja el JSON legible en el Formateador JSON o trocéalo con la chuleta de jq para JSON en la línea de comandos. Si buscas la lista completa de opciones, el manual de curl lo recoge todo, y la referencia de HTTP de MDN explica la semántica que hay detrás de cada método y cabecera.