DEV Community

Cover image for Herramientas Gratuitas Online para Probar APIs: Guía Práctica
Roobia
Roobia

Posted on • Originally published at apidog.com

Herramientas Gratuitas Online para Probar APIs: Guía Práctica

No necesita una licencia de pago para probar una API correctamente. Con una herramienta gratuita —en navegador, escritorio u open source— puede enviar solicitudes, validar códigos de estado, comprobar el cuerpo de la respuesta y ejecutar una pequeña suite de regresión antes de publicar. La clave no es encontrar “una herramienta gratis”, sino elegir una cuyo plan gratuito no bloquee las funciones que necesitará cuando el proyecto crezca.

Prueba Apidog hoy

Esta guía compara herramientas gratuitas de prueba de API que funcionan bien en escenarios reales. Para cada una, verá qué ofrece el nivel gratuito, dónde están los límites y cómo evaluarla con un flujo práctico antes de adoptarla.

Qué significa realmente “gratuito en línea”

“En línea” puede significar tres cosas distintas:

  1. Herramienta 100% navegador: no instala nada y trabaja desde una pestaña.
  2. Aplicación de escritorio con sincronización en la nube: instala un cliente, pero sus colecciones se sincronizan.
  3. Herramienta open source: gratuita, pero normalmente la ejecuta o aloja usted.

Antes de elegir, revise estos límites frecuentes:

  • Colaboración: muchas herramientas son gratis para uso individual, pero cobran cuando se suma el equipo.
  • Historial y monitorización: algunos planes gratuitos guardan pocos días de resultados.
  • Automatización: las ejecuciones programadas o desde CI/CD suelen estar medidas.

Si está definiendo su estrategia de pruebas, empiece por distinguir entre un escenario de prueba y un caso de prueba.

Herramientas gratuitas que merece la pena probar

Apidog

Apidog es una plataforma todo en uno para diseño, depuración, pruebas automatizadas, mocking y documentación de APIs.

En el plan gratuito puede trabajar con:

  • REST
  • GraphQL
  • SOAP
  • WebSocket
  • Escenarios de prueba con solicitudes encadenadas
  • Aserciones visuales
  • Servidor de mock integrado
  • Sin tarjeta de crédito

Un flujo práctico en Apidog sería:

  1. Crear o importar una API.
  2. Definir variables de entorno como base_url y token.
  3. Enviar una solicitud inicial, por ejemplo POST /login.
  4. Extraer un valor de la respuesta, como access_token.
  5. Reutilizarlo en una segunda solicitud, por ejemplo GET /profile.
  6. Añadir aserciones sobre código de estado y campos del JSON.
  7. Ejecutar el escenario completo como una suite.

Ejemplo de comprobaciones que debería añadir:

status = 200
body.user.id existe
body.user.email contiene "@"
response time < 500ms
Enter fullscreen mode Exit fullscreen mode

Apidog se ejecuta como aplicación de escritorio en Windows, macOS y Linux, con sincronización en la nube. Es útil si quiere diseñar, simular, documentar y probar APIs sin unir varias herramientas. Puede descargar Apidog y empezar en el nivel gratuito.

Hoppscotch

Hoppscotch es una herramienta basada en navegador y open source. No requiere instalación y funciona bien para pruebas rápidas de REST, GraphQL y WebSocket.

Úsela si necesita:

  • Enviar solicitudes desde el navegador.
  • Crear colecciones simples.
  • Gestionar entornos.
  • Probar APIs sin configurar una aplicación de escritorio.

Flujo mínimo recomendado:

1. Crear un entorno "staging".
2. Definir base_url.
3. Enviar GET {{base_url}}/health.
4. Verificar status 200.
5. Guardar la solicitud en una colección.
Enter fullscreen mode Exit fullscreen mode

Su punto fuerte es la velocidad y la baja fricción. Su límite principal está en colaboración avanzada, historial y automatización compleja.

Postman nivel gratuito

Postman es una opción conocida para muchos equipos. El nivel gratuito cubre solicitudes manuales, colecciones, entornos y una cantidad limitada de ejecuciones automatizadas mensuales.

Un ejemplo básico de test en Postman:

pm.test("status es 200", function () {
  pm.response.to.have.status(200);
});

pm.test("la respuesta contiene userId", function () {
  const json = pm.response.json();
  pm.expect(json).to.have.property("userId");
});
Enter fullscreen mode Exit fullscreen mode

Es una buena opción si su equipo ya conoce su flujo de trabajo. El límite suele aparecer en colaboración, volumen de llamadas y ejecuciones automatizadas. Si lo está comparando con otras opciones, revise esta guía sobre cómo probar APIs con Postman.

Insomnia

Insomnia es un cliente de escritorio enfocado en depuración para REST, GraphQL y gRPC. Su interfaz es limpia y cómoda para pruebas individuales o suites pequeñas.

Úselo si quiere:

  • Depurar endpoints rápidamente.
  • Trabajar desde escritorio.
  • Mantener una interfaz simple.
  • Probar REST, GraphQL o gRPC sin demasiada configuración.

Un flujo típico:

1. Crear una colección por servicio.
2. Definir entornos para local, staging y producción.
3. Guardar tokens como variables.
4. Probar endpoints críticos.
5. Añadir scripts o comprobaciones donde aplique.
Enter fullscreen mode Exit fullscreen mode

Para pasos prácticos, consulte el tutorial sobre cómo usar Insomnia para probar una API.

SoapUI open source

SoapUI sigue siendo una opción sólida para APIs SOAP y también soporta REST. La edición open source es gratuita y fuerte en pruebas funcionales y basadas en datos.

Tiene sentido si trabaja con:

  • Servicios SOAP heredados.
  • WSDL.
  • XML.
  • Pruebas funcionales con múltiples datos de entrada.

Ejemplo de validación típica en SOAP:

1. Importar el WSDL.
2. Generar operaciones.
3. Crear una solicitud SOAP.
4. Ejecutarla contra el endpoint.
5. Validar status HTTP.
6. Validar nodos XML específicos en la respuesta.
Enter fullscreen mode Exit fullscreen mode

Su desventaja es que es una aplicación Java más pesada, y las funciones de reporting más avanzadas están en ReadyAPI.

Thunder Client

Thunder Client es una extensión para VS Code. Si ya trabaja dentro del editor, puede probar APIs sin cambiar de contexto.

Úselo si quiere:

  • Ejecutar solicitudes desde VS Code.
  • Guardar colecciones junto al proyecto.
  • Probar endpoints durante el desarrollo.
  • Evitar abrir una aplicación separada.

Flujo recomendado:

1. Instalar la extensión en VS Code.
2. Crear una colección por módulo.
3. Configurar variables de entorno.
4. Ejecutar solicitudes desde el editor.
5. Añadir pruebas sin scripts donde aplique.
Enter fullscreen mode Exit fullscreen mode

El nivel gratuito funciona bien para solicitudes individuales y colecciones. La sincronización basada en Git y algunas funciones de equipo son de pago.

Tabla comparativa

Herramienta Tipo Protocolos Fortaleza del nivel gratuito Límite principal
Apidog Escritorio + sincronización en la nube REST, GraphQL, SOAP, WebSocket Diseño, pruebas, mock y documentación Equipos grandes necesitan puestos de pago
Hoppscotch Navegador, open source REST, GraphQL, WebSocket Cero instalación y rapidez Automatización más ligera
Postman Escritorio + nube REST, GraphQL, gRPC Familiar y bien documentado Ejecuciones medidas y puestos de pago
Insomnia Escritorio REST, GraphQL, gRPC UX limpia para depuración Suite de pruebas más limitada
SoapUI Escritorio, open source SOAP, REST Pruebas SOAP y data-driven Aplicación pesada e informes de pago
Thunder Client Extensión de VS Code REST, GraphQL Comodidad dentro del editor Sincronización y funciones de equipo de pago

Cómo elegir una herramienta

Empiece por los protocolos.

  • Si solo usa REST, casi todas sirven.
  • Si usa GraphQL, revise soporte para queries, variables y entornos.
  • Si usa SOAP, considere un probador de API SOAP en línea o SoapUI.
  • Si usa WebSocket, limite la búsqueda a herramientas que lo soporten explícitamente, como Apidog o Hoppscotch.

Después evalúe navegador vs escritorio:

  • Use navegador si quiere cero instalación.
  • Use escritorio si necesita acceder a localhost, redes privadas, archivos grandes o trabajar offline.
  • Use escritorio con sincronización en la nube si quiere acceso local y continuidad entre máquinas.

Luego pruebe el mismo flujo en cada herramienta:

1. Crear un entorno "staging".
2. Definir base_url.
3. Enviar POST /login.
4. Guardar access_token desde la respuesta.
5. Enviar GET /me usando ese token.
6. Validar status 200.
7. Validar un campo del cuerpo.
8. Ejecutar ambas solicitudes como una suite.
Enter fullscreen mode Exit fullscreen mode

La herramienta que haga este flujo con menos fricción probablemente sea la mejor para su equipo. Para mejorar esas verificaciones, revise cómo escribir aserciones de API útiles.

Herramientas gratuitas y pipelines de CI

Una herramienta gratuita puede servir para CI/CD, pero debe revisar el volumen permitido.

Ejemplos comunes:

  • Postman exporta colecciones que puede ejecutar con Newman.
  • Hoppscotch tiene CLI.
  • Apidog ejecuta escenarios desde su propio ejecutor y se integra con pipelines.

Un patrón básico de CI sería:

name: api-tests

on:
  push:
    branches:
      - main

jobs:
  test-api:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Ejecutar pruebas de API
        run: |
          echo "Ejecute aquí su CLI o runner de pruebas de API"
Enter fullscreen mode Exit fullscreen mode

El límite del nivel gratuito suele ser la cantidad de ejecuciones automatizadas, no la capacidad de automatizar. Una suite nocturna puede ser suficiente. Una suite en cada commit dentro de un repositorio con mucho tráfico puede requerir un plan de pago.

Si su objetivo es CI/CD, esta guía sobre automatización de pruebas de API en CI/CD cubre los patrones principales.

Qué debe validar una prueba de API

Evite llamar “prueba” a una solicitud que solo se ejecuta. Una prueba útil afirma algo concreto.

Como mínimo, valide:

1. Código de estado.
2. Estructura del cuerpo.
3. Campos obligatorios.
4. Valores críticos para el negocio.
5. Tiempo de respuesta aceptable.
Enter fullscreen mode Exit fullscreen mode

Ejemplo de aserciones para un endpoint GET /orders/{id}:

status = 200
body.id existe
body.status está en ["pending", "paid", "cancelled"]
body.total > 0
body.currency = "USD"
response time < 700ms
Enter fullscreen mode Exit fullscreen mode

Los códigos de estado HTTP que debe usar una API REST son una buena base para definir estas comprobaciones. Una prueba que solo valida 200 puede pasar aunque la respuesta sea incompleta o incorrecta.

Errores comunes con herramientas gratuitas

1. Elegir una herramienta solo para “probarla”

No elija una herramienta que sabe que reemplazará pronto. Evalúe si el plan gratuito puede acompañar al proyecto durante meses.

2. No usar entornos desde el primer día

Evite esto:

https://staging.api.com/users
https://staging.api.com/orders
https://staging.api.com/payments
Enter fullscreen mode Exit fullscreen mode

Use variables:

{{base_url}}/users
{{base_url}}/orders
{{base_url}}/payments
Enter fullscreen mode Exit fullscreen mode

Y defina entornos:

local:    http://localhost:3000
staging:  https://staging.api.com
prod:     https://api.com
Enter fullscreen mode Exit fullscreen mode

3. Codificar tokens en cada solicitud

Evite duplicar tokens manualmente. Guárdelos como variables:

Authorization: Bearer {{access_token}}
Enter fullscreen mode Exit fullscreen mode

Si la herramienta lo permite, extraiga access_token automáticamente desde la respuesta de login.

4. Ignorar la latencia

Si un endpoint que debería responder en 100ms tarda 800ms, eso es una señal. No necesita una herramienta de carga para detectar regresiones simples.

Para pruebas de carga más deliberadas, consulte este tutorial de pruebas de rendimiento de API.

5. No exportar el trabajo

Los planes gratuitos pueden cambiar. Exporte sus colecciones y manténgalas en control de versiones cuando sea posible.

Ejemplo de estructura:

api-tests/
  collections/
    users.json
    orders.json
  environments/
    local.json
    staging.json
  README.md
Enter fullscreen mode Exit fullscreen mode

Navegador vs escritorio en detalle

Las herramientas de navegador son cómodas porque no requieren instalación. Sin embargo, están sujetas al sandbox de seguridad del navegador. Eso puede afectar:

  • Llamadas a localhost.
  • Acceso a redes privadas.
  • Cargas de archivos grandes.
  • Payloads binarios.
  • Comportamiento CORS.

Antes de adoptar una herramienta de navegador, pruebe que puede acceder a su API local:

GET http://localhost:3000/health
Enter fullscreen mode Exit fullscreen mode

Las aplicaciones de escritorio evitan muchos de esos límites. Pueden abrir conexiones de red directamente, acceder a servicios locales y trabajar mejor con cargas grandes. También pueden seguir funcionando sin conexión.

El coste es instalar y actualizar la aplicación. Por eso muchos equipos prefieren una aplicación de escritorio con sincronización en la nube: mantiene el acceso local y permite continuar el trabajo en varias máquinas.

Cómo mantener saludable una suite gratuita de pruebas

Una suite se degrada si no se mantiene. Los endpoints cambian, los campos se renombran y las aserciones quedan obsoletas.

Haga una revisión periódica:

Cada 2-4 semanas:
1. Eliminar endpoints obsoletos.
2. Actualizar URLs o rutas modificadas.
3. Revisar aserciones rotas.
4. Renombrar pruebas ambiguas.
5. Mover solicitudes a carpetas por flujo.
6. Exportar la colección actualizada.
Enter fullscreen mode Exit fullscreen mode

Use nombres descriptivos.

Evite:

prueba 1
test users
request final
Enter fullscreen mode Exit fullscreen mode

Prefiera:

crear usuario con email válido
rechazar login con contraseña incorrecta
crear pedido con moneda inválida
obtener perfil con token expirado
Enter fullscreen mode Exit fullscreen mode

Agrupe por flujos reales:

Autenticación/
  login exitoso
  login con contraseña incorrecta
  refresh token

Pedidos/
  crear pedido
  pagar pedido
  cancelar pedido
Enter fullscreen mode Exit fullscreen mode

La misma disciplina que ayuda a definir un caso de prueba también mejora una colección de solicitudes de API.

Preguntas frecuentes

¿Las herramientas gratuitas de prueba de API son suficientes para producción?

Sí, para muchos equipos. Los niveles gratuitos suelen cubrir creación de solicitudes, entornos, aserciones y automatización básica. Normalmente se pasa a un plan de pago por colaboración, historial más largo o CI/CD de alto volumen.

¿Puedo probar APIs SOAP con herramientas gratuitas?

Sí. Apidog soporta SOAP en su nivel gratuito, y SoapUI open source está diseñado para ese tipo de servicios. SOAP suele requerir XML, envoltorios específicos y a veces WSDL, por lo que conviene usar una herramienta con soporte explícito. Puede consultar la especificación oficial de SOAP del W3C para detalles del protocolo.

¿Qué diferencia hay entre una herramienta de navegador y una de escritorio?

Una herramienta de navegador funciona sin instalación, pero puede estar limitada por seguridad del navegador, CORS o acceso a red local. Una herramienta de escritorio puede acceder mejor a localhost, redes privadas, archivos grandes y trabajo offline.

¿Las herramientas gratuitas soportan suites automatizadas?

La mayoría sí. Puede encadenar solicitudes, agregar aserciones y ejecutarlas como suite. Postman puede combinarse con Newman, mientras que Hoppscotch y Apidog tienen sus propios ejecutores. El límite suele ser la cantidad de ejecuciones automatizadas disponibles en el plan gratuito.

¿Con qué herramienta debería empezar un equipo pequeño?

Empiece con una herramienta que cubra diseño, pruebas y mocking para evitar añadir productos más adelante. Apidog y Hoppscotch son buenas opciones para equipos pequeños en sus niveles gratuitos. Ejecute el mismo flujo de dos solicitudes encadenadas con aserciones y quédese con la que resulte más fluida para su stack.

Top comments (0)