Tu equipo de frontend está bloqueado. El diseño está aprobado, las pantallas están a medio construir y lo único que se interpone es una API que aún no existe. El backend todavía está a un sprint de distancia, por lo que la interfaz de usuario no tiene nada real a lo que llamar. La solución provisional habitual es un mock local, y funciona hasta el momento en que cierras tu portátil. Entonces, el endpoint al que tu compañero de equipo en otra zona horaria estaba accediendo se apaga.
Esa es la brecha que Apidog cierra con Cloud Mock. En lugar de un mock que vive y muere en una máquina, obtienes una URL pública alojada en mock.apidog.com que permanece activa las 24 horas del día. Los desarrolladores de frontend, QA y socios pueden acceder a endpoints realistas antes de que se envíe una sola línea de código de backend. Si primero quieres una visión más amplia de lo que el mocking aporta a un equipo, nuestra introducción sobre qué es un mock de API y cuándo usarlo sienta las bases. Para la mecánica de cómo una URL de mock pública encaja en el manejo de solicitudes, la referencia de MDN sobre el modelo de solicitud/respuesta HTTP es un buen recordatorio.
Qué es Cloud Mock y por qué los mocks locales se quedan cortos
Apidog genera un endpoint mock para cada API que diseñas. Por defecto, ese mock es un mock local: se ejecuta desde tu instancia de Apidog y responde mientras tu máquina está encendida. En el momento en que apagas, el endpoint deja de responder. Eso está bien para la depuración individual. Se desmorona en el instante en que otra persona depende de la URL.
Cloud Mock es la solución. Es un endpoint mock continuamente disponible que persiste independientemente de cualquier máquina individual. Las computadoras de tus compañeros de equipo pueden estar apagadas, tu portátil puede estar en una mochila, y el mock en la nube sigue respondiendo a las solicitudes 24/7. El endpoint reside en el servicio alojado de Apidog, por lo que la disponibilidad no está ligada a quién está en línea.
El beneficio práctico es una transferencia limpia. Diseñas el contrato, activas Cloud Mock y compartes una URL. El frontend se construye con datos realistas, QA escribe casos de prueba con formas de respuesta reales y un socio que se integre contigo puede comenzar a conectar su cliente de inmediato. Nadie espera al backend, y nadie te espera a ti para mantener un proceso en ejecución. Si estás coordinando esto entre regiones, los patrones en compartir servidores mock y entornos con equipos globales profundizan en el flujo de trabajo.
Habilita Cloud Mock y obtén tu URL pública
Veamos un ejemplo con una API realista. Digamos que estás construyendo un servicio de users con un endpoint GET /users que devuelve una lista de registros de clientes. Así es como lo conviertes en un endpoint en la nube compartible.
Paso 1: activa Cloud Mock
Abre tu proyecto y ve a Project Settings > Feature Settings > Mock Settings (Configuración del Proyecto > Configuración de Características > Configuración de Mocks). Activa Cloud Mock. Ese es el interruptor que le indica a Apidog que aloje tus mocks en su servicio siempre activo en lugar de solo servirlos localmente.
Esto solo se hace una vez por proyecto. Una vez activado, cada endpoint en el proyecto obtiene una URL de mock en la nube junto con su URL local.
Paso 2: copia la URL del mock en la nube
Abre el endpoint que quieres compartir, GET /users en este caso. Ve a su pestaña Mock y copia la URL de Cloud Mock. Obtendrás algo con esta forma:
https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi
La estructura de la ruta sigue un patrón: mock.apidog.com/m1/<projectId>-<num>-<env>/<path>. Apidog lo construye por ti, para que no tengas que ensamblarlo manualmente. Ten en cuenta que la documentación muestra esto mediante un ejemplo en lugar de publicar una plantilla fija, así que trata la URL copiada como la fuente de verdad en lugar de intentar construir una por tu cuenta.
Paso 3: prueba el mock instantáneamente dentro de Apidog
Antes de entregar la URL a alguien, confirma que devuelve lo que esperas. En la misma pestaña Mock, envía una solicitud de prueba contra la URL del mock. Apidog dispara la solicitud y te muestra la respuesta allí mismo. Obtienes una lectura instantánea de si los datos generados se ven correctos.
Un mock de GET /users podría regresar así:
[
{
"id": 1,
"name": "Amelia Turner",
"email": "amelia.turner@example.com",
"city": "Portland"
},
{
"id": 2,
"name": "Marcus Bell",
"email": "marcus.bell@example.com",
"city": "Austin"
}
]
Esos valores no están codificados. Apidog lee los nombres y tipos de campo de tu esquema y genera datos plausibles para que coincidan, lo que hace que el mock sea útil para un frontend que renderiza una tabla de aspecto real.
Paso 4: abre la URL en un navegador
Para una solicitud GET, la URL del mock en la nube funciona directamente en un navegador web. Pégala en la barra de direcciones y verás la respuesta JSON. Esta es la verificación de cordura más rápida que puedes entregar a una parte interesada no técnica: sin cliente, sin curl, solo un enlace que devuelve datos.
Para cualquier cosa más allá de un vistazo rápido, tu frontend lo llama como cualquier otro endpoint:
curl "https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
Ese es todo el ciclo. Diseña el endpoint, habilita Cloud Mock, copia la URL y tu equipo se desbloquea.
Asegura el mock con autenticación por token
Una URL pública es conveniente, y a veces demasiado conveniente. Si tu mock refleja una característica no lanzada o una integración con un socio que preferirías no exponer, puedes protegerla.
Ve a Project Settings > Feature Settings > Mock Settings (Configuración del Proyecto > Configuración de Características > Configuración de Mocks) y establece el permiso de acceso en Token Authentication (Autenticación por Token). Una vez activado, cada solicitud debe llevar un apidogToken válido, y las solicitudes sin él serán rechazadas. Puedes proporcionar el token de tres maneras:
Como parámetro de cadena de consulta de URL, que es lo que ya utiliza la URL copiada:
curl "https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
Como encabezado de solicitud, lo que mantiene el token fuera de la URL y de los registros del servidor:
curl "https://mock.apidog.com/m1/2689726-0-default/users" \
-H "apidogToken: GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"
O como parámetro de cuerpo llamado apidogToken en una solicitud form-data o x-www-form-urlencoded, lo que se adapta a clientes que envían cuerpos de formulario.
Para el código frontend, el enfoque del encabezado suele ser el más limpio. Mantiene el token fuera de cualquier cosa que registre URLs completas y separa la credencial de la ruta del recurso:
const res = await fetch(
"https://mock.apidog.com/m1/2689726-0-default/users",
{ headers: { apidogToken: "GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi" } }
);
const users = await res.json();
Una cosa a tener en cuenta: si habilitas la autenticación por token después de haber compartido una URL simple, cada consumidor deberá agregar el token o sus llamadas comenzarán a fallar. Coordina el cambio para que QA y los socios no se queden mirando solicitudes rechazadas.
Genera datos realistas y conscientes de la región con locales
Un mock que devuelve "name": "string" para cada registro no le enseña nada a tu interfaz de usuario. Un mock que devuelve nombres, direcciones y números de teléfono de aspecto real permite al frontend detectar errores de diseño, desbordamientos de texto y problemas de formato antes de que lleguen los datos reales. Apidog maneja esto con Faker.js por debajo, y los controles de localización son donde se vuelve realmente útil para productos internacionales.
Cómo funciona la configuración regional predeterminada
Por defecto, Faker sigue la configuración de idioma de tu proyecto. Eso se configura en Project Settings > Basic Settings (Configuración del Proyecto > Configuración Básica), y cualquier idioma que elijas allí se convierte en la configuración regional predeterminada para todos los valores mock generados. Configura el proyecto en francés y tus nombres y direcciones mock volverán con un toque francés sin ningún trabajo por campo.
Anula la configuración regional para todo el proyecto
Si quieres datos mock en una configuración regional específica que difiera del idioma del proyecto, puedes anularla. Ve a Project Settings > Feature Settings > Mock Settings (Configuración del Proyecto > Configuración de Características > Configuración de Mocks) y elige una configuración regional de Faker del menú desplegable. Esa anulación prevalece sobre la configuración de idioma predeterminada de Configuración Básica para cada campo en el proyecto.
Esto es útil cuando estás probando la internacionalización. Apunta la configuración regional del proyecto a Japón y cada dirección, nombre y número de teléfono generado reflejará esa región, para que puedas ver cómo tu interfaz de usuario se comporta con scripts no latinos y diferentes formatos de dirección. La generación automática de este tipo de datos conscientes del esquema es un tema en sí mismo, y el tutorial sobre el mock inteligente de Apidog y cómo lee tu esquema cubre el lado de la generación en detalle.
Anula la configuración regional campo por campo
A veces necesitas un campo en una configuración regional diferente al resto, por ejemplo, una lista de clientes que mezcla regiones. Puedes establecer la configuración regional directamente en la expresión mock usando el locale parameter:
{{$person.fullName(locale='ja')}}
Eso produce nombres japoneses como 田中 太郎 solo para ese campo, mientras que el resto de la respuesta sigue la configuración regional del proyecto. La precedencia se ejecuta en tres niveles: una configuración regional a nivel de campo anula la configuración regional a nivel de proyecto, que a su vez anula el valor predeterminado del idioma de Configuración Básica. Así que estableces un valor predeterminado de proyecto sensato y solo recurres a las anulaciones a nivel de campo donde realmente necesitas la excepción.
Una nota rápida y honesta sobre el alcance: la documentación muestra ja como ejemplo práctico y no publica una lista completa de locales compatibles, así que confirma el código exacto para tu región objetivo en la documentación de mock de Apidog antes de confiar en él. Las propias convenciones de Faker están documentadas en la referencia de locale de Faker.js.
Coincide también la zona horaria
Existe un control paralelo para la hora. Un valor predeterminado a nivel de proyecto se encuentra en Project Settings > Feature Settings > Mock Settings (Configuración del Proyecto > Configuración de Características > Configuración de Mocks), y puedes anularlo por campo con el timeZone parameter dentro de una expresión mock. Si tu interfaz de usuario renderiza marcas de tiempo, esto mantiene los valores de createdAt generados consistentes con la región que estás simulando en lugar de usar por defecto la ubicación de tu servidor.
Entre los controles de locale y zona horaria, puedes configurar un mock que imite de manera convincente una base de usuarios japonesa, alemana o una cohorte internacional mixta, todo desde el mismo esquema de endpoint. Para el conjunto más amplio de escenarios que esto desbloquea, el resumen de casos de uso prácticos de mocking de API vale la pena revisar.
Cloud Mock versus un mock autoalojado
Cloud Mock es la opción alojada de Apidog, y cubre a la mayoría de los equipos. Si tu organización tiene reglas de residencia de datos o una política contra el enrutamiento de tráfico de prueba a través de la nube de un proveedor, Apidog también admite ejecutar el servicio mock en tu propia infraestructura. La compensación es directa: la opción en la nube es de configuración cero y siempre activa, mientras que el autoalojamiento te da control a costa de ejecutar el servicio tú mismo. Si esa es tu situación, la guía para autoalojar el servidor mock de Apidog lo explica. Para los equipos que sopesan las opciones alojadas una al lado de la otra, la comparación de herramientas de mocking de API en línea presenta el panorama.
Sobre la restricción de planes, una respuesta directa: las características de Cloud Mock y localización documentadas aquí no establecen un requisito de plan específico, por lo que lo más honesto es verificar la disponibilidad actual en tu propia cuenta en lugar de tomar un número de una publicación de blog. Puedes descargar Apidog y probar el flujo de principio a fin para ver exactamente lo que incluye tu espacio de trabajo.
Automatiza el flujo de trabajo con la CLI de Apidog
El mocking en Apidog es una capacidad de GUI y de la nube. Las respuestas mock se generan automáticamente a partir del esquema de tu endpoint y son servidas por el motor alojado de Apidog, no por algo que ejecutes en una terminal. Así que el planteamiento honesto es este: la CLI de Apidog no inicia ni sirve un servidor mock. Lo que hace es mantener precisas las entradas de tu mock.
La CLI y los agentes de codificación de IA como Cursor o Claude Code pueden crear y actualizar los endpoints y esquemas en tu proyecto. Dado que el mock en la nube lee esos esquemas para generar datos, mantener la especificación actualizada mantiene la salida del mock fiel a medida que la API evoluciona. Cuando utilizas una herramienta de agente para agregar un campo, el mock lo refleja sin una edición manual.
Luego, una vez que el mock ha desbloqueado el trabajo de frontend y el backend real se ha implementado, los escenarios de prueba del mismo proyecto se ejecutan sin interfaz gráfica contra él. El comando de ejecución de la CLI valida el backend en vivo contra el mismo contrato que describió el mock:
apidog run -t <scenario_id> -e <env_id> -r cli
Ese único comando ejecuta un escenario de prueba guardado contra un entorno e informa los resultados, de modo que el mock que desbloqueó la interfaz de usuario y las pruebas que verifican el backend se remontan a una única fuente de verdad. Abre tu escenario en Apidog y copia el comando generado con el ID de escenario -t y el ID de entorno -e ya rellenados, en lugar de ensamblar las banderas manualmente. La integración de esto en una pipeline se cubre en la guía para ejecutar Apidog en una pipeline de CI/CD.
Preguntas Frecuentes
¿La URL del mock en la nube sigue funcionando cuando cierro Apidog?
Sí, ese es el objetivo principal de Cloud Mock. A diferencia de un mock local, que deja de responder cuando la máquina anfitriona se apaga, el mock en la nube se sirve desde la infraestructura de Apidog y permanece disponible las 24 horas del día, los 7 días de la semana. Tus compañeros de equipo pueden acceder a él independientemente de si tu computadora está encendida.
¿Puedo usar la URL del mock en la nube directamente en un navegador?
Para solicitudes GET, sí. Pega la URL completa, incluyendo el parámetro de consulta apidogToken, en la barra de direcciones y verás la respuesta JSON. Para otros métodos o para mantener el token fuera de tu historial de URL, llámala con una herramienta como curl o tu cliente frontend y pasa el token como un encabezado en su lugar.
¿Qué sucede con las solicitudes que no incluyen el token?
Si has configurado el permiso de acceso a Autenticación por Token, cualquier solicitud sin un apidogToken válido será rechazada. Suminístralo como un parámetro de cadena de consulta, un encabezado de solicitud o un parámetro de cuerpo en una solicitud de formulario. Si habilitas la autenticación por token después de compartir una URL simple, informa a tus consumidores para que puedan agregar el token antes de que sus llamadas comiencen a fallar.
¿Cómo obtengo datos mock que coincidan con un país específico?
Configura la configuración regional de tu proyecto en Configuración Básica, o anúlala para todo el proyecto en Configuración de Características > Configuración de Mocks, o anula un solo campo con el parámetro locale en la expresión mock, como {{$person.fullName(locale='ja')}}. El nivel de campo prevalece sobre el nivel de proyecto, que a su vez prevalece sobre el valor predeterminado de Configuración Básica. El tutorial de mock inteligente muestra cómo la generación consciente del esquema se relaciona con esto.
¿Debería usar Cloud Mock o una herramienta de mock sin interfaz gráfica?
Cloud Mock es adecuado para equipos que desean un endpoint alojado y sin mantenimiento, vinculado a su diseño de API. Si necesitas mocks incrustados en una compilación automatizada sin ninguna GUI, la revisión de herramientas de mock sin interfaz gráfica compara las opciones y dónde encaja cada una. La especificación de la OpenAPI Initiative sustenta la mayoría de estas herramientas, por lo que una especificación limpia vale la pena, sea cual sea la ruta que elijas.
Conclusión
Un mock que solo vive en tu portátil desbloquea exactamente a una persona. Cloud Mock lo convierte en una URL pública mock.apidog.com contra la que todo tu equipo puede construir, con autenticación por token cuando necesites protegerlo y controles de configuración regional cuando tus datos necesiten parecer reales para una región específica. Diseña el endpoint, activa el interruptor, comparte el enlace y el frontend deja de esperar al backend. Descarga Apidog para configurar tu primer mock en la nube compartible, gratis y sin necesidad de tarjeta de crédito.