¿Qué pasa si el slug ya está cogido?

POST /api/mocks responde 409 con el código de error slug_taken y no crea nada. El slug sigue no disponible mientras el mock que lo tiene esté vivo, y vuelve a estar disponible en cuanto ese mock se elimina o expira. Se devuelve el mismo código para nombres que no se pueden usar por otros motivos, así que léelo simplemente como: elige otro slug.

¿Un slug personalizado hace público el mock?

No más que antes, pero un slug legible es más fácil de adivinar que uno aleatorio, así que quien adivine la URL puede llamarla. Mantén los secretos fuera de la respuesta. El registro de peticiones sigue siendo privado por defecto: solo se abre con el token de administrador, salvo que hayas creado el mock con logs_public .

¿Puedo cambiar el slug más adelante?

No. El slug se fija al crear el mock, y actualizar el mock con PUT lo ignora. Para pasar a otra dirección, crea un mock nuevo con el slug nuevo, apunta a él a tus clientes y elimina el antiguo.

URL de mock estable con un slug personalizado

Elige tú el slug y la URL del mock sobrevive a cada eliminación y recreación: ponla una vez en tu .env, en el CI y en Postman, y deja de perseguir direcciones nuevas.

Una URL de mock aleatoria es perfecta para una prueba desechable y un fastidio para todo lo que tiene que recordarla. Si recreas el mock, la dirección cambia, y el valor de tu archivo .env, de los secretos del CI y del entorno compartido de Postman queda obsoleto. Un slug personalizado te deja elegir la dirección una sola vez: pasa slug al crear el mock, con la API, la CLI o el formulario web, y https://quickmock.dev/m/my-app-payments-dev seguirá funcionando tras eliminar y recrear el mock, mientras nadie más reclame el nombre.

¿Por qué estorba una URL de mock aleatoria?

Cada mock creado sin slug recibe uno aleatorio de 12 caracteres, y para una prueba desechable es justo lo que hace falta. Deja de serlo en cuanto la URL se anota en algún sitio. Si eliminas el mock y lo creas de nuevo, obtienes otro slug, y cada lugar que recordaba la dirección anterior apunta ahora a la nada: el archivo .env del portátil de un compañero, el secreto en los ajustes del CI, el entorno de una colección compartida de Postman, la URL base en la configuración del sandbox de un socio.

Un slug personalizado convierte la dirección en algo que eliges una sola vez. https://quickmock.dev/m/my-app-payments-dev se puede pegar en todos esos sitios y olvidarse. El mock que hay detrás todavía se puede eliminar, sustituir por otra respuesta o dejar que expire y volver a crear; mientras lo crees con el mismo slug, la URL que usan tus clientes no cambia nunca.

Además, simplemente es más cómodo. Un nombre legible en una línea de log, en un stack trace o en un pipeline que falla te dice qué mock está implicado sin tener que buscarlo.

¿Cómo se crea un mock con tu propio slug?

Pasa slug al crear el mock. En la API es un campo JSON más:

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{"slug":"my-app-payments-dev","method":"GET","response_status":200}'

La CLI tiene una opción para ello, y el formulario web tiene un campo de slug personalizado junto al sufijo de ruta:

quickmock create -slug my-app-payments-dev -s 200 -b '{"status":"ok"}'

Un slug tiene de 4 a 48 caracteres: letras minúsculas, dígitos y guiones, y empieza y termina con una letra o un dígito. Los espacios al principio y al final se recortan y las mayúsculas se pasan a minúsculas, así que My-App-Dev se convierte en my-app-dev. Si omites el campo, o lo envías vacío, obtienes un slug aleatorio como antes. Un slug con un formato incorrecto se rechaza con 422 validation_failed y no se crea nada.

Si el nombre no se puede usar, la respuesta es 409 slug_taken. Es la misma respuesta tanto si otro mock activo tiene el slug como si el nombre no está disponible por otro motivo, así que elige otro e inténtalo de nuevo.

¿Cuánto tiempo sigue siendo tuya la URL?

Un mock con slug personalizado vive como cualquier otro mock. Expira tras los ttl_seconds que indiques, o tras el valor por defecto del servidor si no indicas ninguno, y nunca puede vivir más de 30 días desde el momento de su creación. Hasta entonces la URL sigue respondiendo.

Para mantenerlo, amplía su vida con el token de administrador que recibiste al crearlo:

curl -X POST https://quickmock.dev/api/mocks/my-app-payments-dev/extend \
  -H "Authorization: Bearer $ADMIN_TOKEN"

Eso adelanta la fecha de expiración, pero nunca más allá del límite de 30 días. Cuando se alcanza ese límite, la llamada devuelve 409 ttl_cap_reached y el mock expira según lo previsto.

Un slug se libera en cuanto desaparece su mock. Elimina el mock con DELETE /api/mocks/<slug>, o déjalo expirar, y la siguiente petición de creación podrá reclamar el mismo slug, con otro método, estado o cuerpo si quieres. Así se renueva una URL estable: la dirección se mantiene, el mock que hay detrás es nuevo y viene con un token de administrador nuevo.

¿Qué suele salir mal?

Poner secretos en la respuesta. Un slug legible es fácil de adivinar, y quien lo adivina puede llamar a la URL. Trata el cuerpo de la respuesta como público: nada de claves reales, tokens ni datos personales. El registro de peticiones es otra cosa y es privado por defecto: solo se lee con el token de administrador, salvo que hayas creado el mock con logs_public.
Elegir un nombre genérico. Quien llega primero lo obtiene. Nombres como test, demo o api casi seguro que ya están cogidos. Añade al slug un prefijo con tu equipo y tu aplicación, por ejemplo acme-checkout-staging.
Dar por hecho que el slug está reservado para ti. Pertenece a un mock solo mientras ese mock está vivo. Cuando expira, cualquiera puede crear un mock con el mismo slug, así que amplía el mock antes de la fecha límite y guarda el token de administrador en un sitio donde lo encuentres.
Esperar poder renombrarlo. El slug queda fijado al crear el mock, y actualizarlo con PUT nunca lo cambia. Para otra dirección, crea un mock nuevo y elimina el antiguo.

Cuándo usar esto

Los slugs aleatorios cambian en cada recreación, así que cualquier configuración que guardó la URL queda obsoleta. Un slug personalizado de 4 a 48 caracteres da al mock una dirección fija y legible que puedes fijar en entornos, secretos del CI y configuraciones de tu equipo.

Crear el mock

curl -X POST https://quickmock.dev/api/mocks \
  -H 'Content-Type: application/json' \
  -d '{
  "slug": "my-app-payments-dev",
  "method": "GET",
  "response_status": 200,
  "content_type": "application/json",
  "response_body": "{\"status\":\"ok\"}"
}'

Llamarlo

curl https://quickmock.dev/m/<slug>

Lo que obtienes

GET /m/my-app-payments-dev -> 200 {"status":"ok"}
second create with the same slug -> 409 slug_taken
(until the first mock is deleted or expires)

Preguntas frecuentes

¿Qué pasa si el slug ya está cogido?: POST /api/mocks responde 409 con el código de error slug_taken y no crea nada. El slug sigue no disponible mientras el mock que lo tiene esté vivo, y vuelve a estar disponible en cuanto ese mock se elimina o expira. Se devuelve el mismo código para nombres que no se pueden usar por otros motivos, así que léelo simplemente como: elige otro slug.
¿Un slug personalizado hace público el mock?: No más que antes, pero un slug legible es más fácil de adivinar que uno aleatorio, así que quien adivine la URL puede llamarla. Mantén los secretos fuera de la respuesta. El registro de peticiones sigue siendo privado por defecto: solo se abre con el token de administrador, salvo que hayas creado el mock con logs_public.
¿Puedo cambiar el slug más adelante?: No. El slug se fija al crear el mock, y actualizar el mock con PUT lo ignora. Para pasar a otra dirección, crea un mock nuevo con el slug nuevo, apunta a él a tus clientes y elimina el antiguo.

Construye el tuyo propio

Crear un mock

Guías relacionadas

← Todas las guías

Última actualización: 2026-10-20