Ayuda de Net Tinker

Quiero… — encontrar la herramienta adecuada

Cada nombre en negrita está escrito exactamente como aparece en la extensión, así que puedes buscarlo con Ctrl+F aquí y encontrarlo igual en la interfaz.

…cambiar lo que hace una petición o una respuesta

Todo esto es una regla. El tipo se elige en el desplegable Tipo de regla al crearla.

…moverme por la extensión

La página de opciones tiene dos filas de mandos, y en qué fila está una cosa te dice a qué afecta. La cabecera lleva lo que gobierna todo: el proyecto en el que estás, después Exportar · Importar ▾ · + Nueva regla, y en la esquina el interruptor maestro, el 🌐 idioma de la interfaz y la ayuda.

La tira de pestañas de debajo abre lo que vive dentro del proyecto activo: 📁 Grupos · 🎭 Escenarios · {{ }} Variables · 🌐 Entornos · 🎯 Alcance · 📡 Capturas · 🗑 Papelera. Solo hay un panel abierto a la vez, y el que dejes abierto es el que te encuentras la próxima vez. El orden es a propósito: los cinco primeros configuran cómo se comportan tus reglas y los dos últimos no configuran nada — 📡 Capturas es el registro de lo que hicieron tus reglas, y 🗑 Papelera es lo que has borrado.

Tu primera regla: qué campos importan de verdad

Pulsa + Nueva regla (en el popup o en la página de opciones). El formulario se abre en Mockear la respuesta (API), que es el caso más común: contestar una petición desde el navegador en vez de dejar que llegue al servidor. Lo que el formulario enseña de entrada es poco —el resto va plegado en cuatro bloques, que se explican justo debajo— y casi todo es opcional. Esto es lo que necesita de verdad un mock JSON:

1. URL / patrón — el único campo sin el cual la extensión no guarda la regla. Por defecto se lee como Contiene, así que con /api/users basta para atrapar todas las URL que lleven ese fragmento. Ver Elegir con qué peticiones coincide una regla.
2. Código de estado — empieza en 200. Es una caja numérica normal con una lista de sugerencias asociada (200, 201, 204, 301, 400, 401, 403, 404, 429, 500, 502, 503…): pincha para elegir una, o escribe directamente el código que quieras.
3. Headers — una regla de mock nueva se abre con Content-Type: application/json ya escrito en la caja, como valor de verdad: puedes editarlo o borrarlo, y lo que se ve es lo que se guarda. Si lo borras, el mock vuelve como texto plano —algo perfectamente legítimo, para reproducir un servidor que no manda el tipo—, y al guardar nadie te repone la cabecera. Abrir una regla que ya existe no le añade nada, ni aunque tenga los headers vacíos.
4. Body de respuesta — lo que recibe quien llama. Los botones { } Formatear y { } Minificar de encima ordenan el JSON, y un aviso debajo te dice si lo que has escrito es JSON válido.

Todo lo demás sirve para afinar la regla o para encontrarla después, y vive en cuatro bloques plegables: Organización (descripción, etiquetas, grupo), Coincidencia avanzada (origen, tipo de match, método), Condiciones adicionales (opcional) (condiciones de header, body e iniciador) y Simulación de red (latencia y código de estado, que se aplican a cualquier tipo de regla). En una regla nueva los cuatro empiezan cerrados; al editar una que ya existe se abre cada bloque que esa regla use, así que un bloque plegado nunca esconde algo que hayas puesto. Dos cosas que conviene hacer antes de cerrar:

• Pega una URL real en URL de prueba (opcional). Te dice al momento si esta regla coincidiría con ella, sin guardar nada y sin lanzar ninguna petición.
• Guarda, recarga la página y mira el icono de la extensión en la barra: lleva un contador de reglas aplicadas en esa pestaña. Si sigue vacío, la regla no se ha aplicado nunca — vete a Por qué una regla puede no estar aplicándose.

Atajo: apuntar toda tu app a otro backend

El caso más repetido de todos —quiero que esto hable con mi servidor local en vez de con producción— no necesita que teclees un patrón. En el formulario, junto al campo Patrón, tienes Apuntar a otro backend: escribe el host de origen y el de destino, pulsa, y la regla queda hecha — patrón, tipo Reemplazar texto en la URL y los dos campos de reemplazo.

Lo que escribe es una regla normal y corriente, así que puedes retocarla después. Y afecta a todas las llamadas a ese host, que es justo lo que se quiere aquí: si solo querías una, usa el panel de DevTools.

Tipos de regla

Cada regla tiene exactamente un tipo, que decide qué ocurre cuando coincide con una petición. El nombre en negrita es el del desplegable Tipo de regla, donde los nueve van agrupados por lo que le hacen a la petición —Mock, Passthrough modificado, Redirect y Block, la división que explica Mock vs. passthrough modificado—; el nombre corto entre corchetes es como aparece ese mismo tipo en el listado de reglas, en el filtro de tipo y en la lista de capturas. Una regla hace una sola de estas cosas — pero una petición puede estar gobernada por varias reglas a la vez, así que combinar dos tipos es cuestión de escribir dos reglas. Ver Cuando varias reglas coinciden con la misma petición.

La latencia no es un tipo de regla

Retrasar una petición era un tipo aparte y ha dejado de serlo. Latencia (ms) vive en el bloque Simulación de red del formulario y se aplica a todos los tipos: un mock llega tarde, una redirección sale tarde, una petición cancelada falla tarde. Si dejas el campo vacío la regla no añade ninguna latencia; 0 no es lo mismo que vacío — es una espera real, aunque sea mínima.

Si lo único que quieres es hacer lento un endpoint, usa el tipo Sin cambios (solo retrasar) y ponle una latencia. Las reglas que eran del antiguo tipo Retraso se convirtieron exactamente en eso, conservando sus milisegundos, la primera vez que abriste esta versión.

Simulación de red: latencia aleatoria, timeout y caos

El bloque Simulación de red del formulario tiene cuatro maneras de hacer que una petición se porte mal, y las cuatro funcionan con cualquier tipo de regla — un mock, una redirección o una regla Sin cambios (solo retrasar) las admiten igual. Todos los campos son opcionales, y vacío significa "esto no". La Latencia (ms) fija está explicada justo arriba; aquí van las otras tres.

Latencia aleatoria

Mín (ms) y Máx (ms), la fila que hay debajo de la latencia fija. Cada petición espera algo distinto entre esos dos valores, extremos incluidos: con 100 y 200 puede salir 100, puede salir 200 y puede salir cualquier cosa de en medio, y se sortea otra vez en cada petición.

• Hacen falta los dos. Con uno solo no hay rango que sortear, así que la regla se comporta como si no hubiera ninguno y manda la Latencia (ms) fija.
• Cuando están los dos, sustituyen a la latencia fija; no se suman. La fija se queda guardada por si vacías el rango, pero mientras el rango esté puesto no se usa.
• Si los escribes al revés (500 y 100) se entiende el rango 100–500. Rechazarlo dejaría la regla sin latencia sin decirte por qué.

Timeout simulado

Timeout simulado (ms) espera ese tiempo y luego hace fallar la petición como lo haría un timeout de red de verdad. Es el vecino de la latencia en el formulario y no es lo mismo:

• Le gana a lo que la regla haga. Una regla que mockea y lleva timeout no entrega nunca su mock: prometer que no llega respuesta le gana a prometer una. Lo único que le gana al timeout es el tipo Cancelar petición.
• No se suma a la latencia. Espera exactamente los milisegundos que escribiste, no la latencia más el timeout: un timeout de 3000 con 200 ms de latencia fallaría a los 3,2 s, y ese 0,2 no lo habría pedido nadie. Que el número de la espera sea el que escribiste es lo único que hace medible un timeout.

Modo caos

Tres campos —% errores, Estado del error y % timeouts— que sortean el desenlace en cada petición. El porcentaje de éxito no se pide: es el que sobra. Con 20 y 10, dos de cada diez peticiones reciben el error, una de cada diez se queda sin respuesta, y las siete restantes hacen exactamente lo que diga la regla.

• El error se sirve como respuesta local, con el Estado del error que digas (500 si lo dejas vacío) y sin cuerpo ni cabeceras: el caos no sabe qué cuerpo tendría sentido, y fabricarte uno sería inventarle a tu página un contrato que no existe.
• El timeout del caos espera lo que la propia regla ya dijera: su Timeout simulado (ms) si lo tiene y, si no, su latencia. Sin ninguna de las dos falla en cuanto pasa un turno, que es lo único honesto cuando nadie ha dicho cuánto esperar.
• Si los dos porcentajes suman más de 100, el error se sirve primero y el timeout se queda con lo que quede hasta 100. No hace falta corregirlo: es lo que hace la extensión para que una suma imposible degrade de forma previsible en vez de romper.
• Donde más se nota es en una regla de tipo Mockear la respuesta (API): ahí el caos le gana a su propio mock, que es justo lo que quiere decir "este endpoint falla el 20% de las veces".

Límite de llamadas y fallo intermitente

Los dos únicos campos de toda la extensión que cuentan peticiones. Los demás miran solo la petición que tienen delante; estos dos miran además cuántas lleva ya esa regla.

De dónde sale la cuenta, que es lo que hay que saber antes de usarlos:

• Es por página, y recargar la reinicia. No es una limitación disimulada: recargar es justo el gesto de quien está probando un límite, y sin él no habría ningún otro botón para volver a empezar.
• La misma página abierta en dos pestañas cuenta dos veces, y cada iframe cuenta aparte: dentro de cada documento vive un motor propio, y ninguno ve lo que hacen los demás.
• La cuenta no se guarda en ningún sitio. Cierra la pestaña y no queda nada: un límite que probaste el martes no puede seguir agotado el jueves.
• Editar otra regla no la toca. Borrar ésta sí: una regla nueva empieza de cero aunque se llame igual.
• Las peticiones que corta no salen del navegador, así que no aparecen ni en la pestaña Network de DevTools ni en el panel de Net Tinker: los dos enseñan lo que de verdad salió. Diez llamadas con un límite de 3 salen ahí como tres filas, y esa diferencia es justamente la prueba de que las otras siete se quedaron. Para verlas las diez, activa Grabar esta pestaña en el popup y abre 📡 Capturas. El panel te lo dice él solo mientras haya una regla así activa.

Y si pones dos a la vez —o los dos con caos— gana el más previsible: primero el Límite de llamadas, luego el Fallo intermitente, y el Modo caos el último. Cruzado el límite ya no hay sorteo que valga: lo que puedes predecir mirando tu regla le gana a lo que no puede predecir nadie.

La consola de la página

Anotar en la consola de la página cuando esta regla coincida es la última casilla del bloque, y la única que no le hace nada a la petición: sale exactamente igual que habría salido. Lo que añade es una línea [Net Tinker] por petición en la consola de la propia página —el nombre de la regla, el método, la URL y qué le pasó— justo al lado de los logs de tu aplicación. Ése es todo el asunto: la misma información ya está en 📡 Capturas, pero en otra ventana, y mientras persigues un fallo estás leyendo la consola, no cambiando de pestaña.

La página también lo ve, y conviene saberlo antes de marcarla. Net Tinker escribe esa línea desde dentro de la página, así que lo que la página haga con su consola —un recolector de errores, un grabador de sesión, una pantalla que estés compartiendo— lo recibe igual. Por eso la línea no lleva nunca cabeceras, cuerpo ni valores de variables: tu preset de auth es literalmente Authorization: Bearer {{token}}, y un token no pinta nada en una consola. Si lo que necesitas es ver qué aplicó la regla, para eso está el detalle de la captura.

Sobrescribir el estado de una respuesta real

Hay dos campos en el formulario que son un código de estado HTTP, y no son lo mismo. Es la confusión más fácil de tener aquí, así que va primero:

El caso para el que existe: quieres ver qué hace tu manejo de errores ante un 500 de ese endpoint, pero con los datos de verdad. Con un mock tendrías que escribir el body entero a mano — y entonces ya no estarías probando contra la respuesta real, que era justo lo que querías conservar.

• Se acepta de 200 a 599. Fuera de ese rango el navegador no puede construir la respuesta, así que un valor de fuera no se aplica en vez de romper la petición.
• El texto de estado se queda vacío. Un 500 arrastrando el OK de la respuesta original se contradice a sí mismo en cuanto lo escribes en un log; y un texto vacío es lo que ya entrega el navegador con HTTP/2 y HTTP/3, que no llevan frase de estado.
• Con 204, 205 o 304 el body se cae, porque esos estados no pueden llevar ninguno. Es exactamente lo que hace el navegador con una respuesta real de ese tipo.
• Deja el campo vacío para conservar el estado real: es la única forma de quitar una sobrescritura.
• En una regla que mockea o que cancela la petición no hace nada, y no es un fallo: ahí no hay ninguna respuesta real que sobrescribir. En el panel de Actividad esa regla aparece como coincidente pero no aplicada. Para un mock, el campo que manda es Código de estado.

Y como cualquier modificador, se combina: una misma regla puede sobrescribir el estado y transformar el body de la respuesta, y cambiarle una cabecera, y llegar tarde.

Mock vs. passthrough modificado

Es la confusión más habitual, así que merece explicarse aparte:

Una forma práctica de distinguirlos mientras depuras: abre la pestaña Network de DevTools. Una petición mockeada nunca aparece ahí (no llegó a la red); una modificada-y-dejada-pasar sí, con la URL/body/headers ya reescritos. La lista de capturas dice lo mismo con palabras, petición a petición: "llegó a la red" o "no llegó a la red".

Es una propiedad de la petición, no de cada regla por separado: en cuanto una de las reglas que coinciden la mockea, la petición ya no sale del navegador, hagan lo que hagan las demás. Un mock con latencia es una respuesta que llega tarde y que sigue sin llegar al servidor — ver Cuando varias reglas coinciden con la misma petición.

Elegir con qué peticiones coincide una regla

Sea del tipo que sea, toda regla parte de un patrón: el desplegable Origen decide si ese patrón se compara con la URL completa o solo con el Host, y el desplegable Tipo de match decide cómo. Los dos están dentro del bloque Coincidencia avanzada del formulario, plegado hasta que lo abras:

En vez de adivinar, pega una URL real en URL de prueba (opcional), la caja que hay justo debajo del patrón. Responde ✓ Coincide o ✗ No coincide mientras escribes, te dice contra qué ha comparado (la URL entera o solo el host) y te avisa si un patrón Regex no compila. No guarda nada ni lanza ninguna petición. Decide con el patrón, el tipo de match, el origen y las exclusiones; el método y las condiciones de header/body/iniciador las nombra en vez de juzgarlas — una URL no lleva método ni body, así que las enumera como lo que no ha podido comprobar en lugar de dar por hecho que sí.

Todo lo de /api/ menos el health check

Un patrón lo bastante amplio como para ser útil suele serlo también para atrapar algo que no querías: el health check que tu panel pide cada cinco segundos, la llamada de login, la única petición que ya lleva un token de verdad. Para eso está Excepto URLs que contengan (una por línea), justo debajo de los tres desplegables de Coincidencia avanzada. Un patrón por línea; si alguno aparece en la URL de la petición, la regla la deja en paz.

Dos cosas de esta caja son deliberadas, y conviene saberlas antes de pelearse con ella:

• Se compara siempre contra la URL entera, aunque Origen esté en Host. Es lo que la hace utilizable en las reglas que más la necesitan: una regla acotada por host no tendría más que un nombre de dominio contra el que comparar, y /api/health no aparece en ninguno. De paso, aquí se puede excluir un subdominio entero (static.example.com) igual de fácil que una ruta.
• Es siempre texto literal, diga lo que diga Tipo de match. Ni regex ni comodines: un . es un punto y un * es un asterisco. Las mayúsculas cuentan, como en todo lo demás. Si de verdad necesitas una expresión regular para describir lo que quieres dejar fuera, la salida de siempre sigue estando ahí — un lookahead negativo en el propio patrón, ^(?!.*health).*api.* en modo Regex.

La caja de URL de prueba tiene en cuenta las exclusiones: una URL excluida responde ✗ La excluye «…» y dice qué línea es la responsable, en vez de prometer una coincidencia que no va a ocurrir.

Además del patrón, una regla puede llevar condiciones extra, en Condiciones adicionales (opcional) del formulario —salvo el Método, que está con los otros dos desplegables en Coincidencia avanzada—. Todas son opcionales, y todas tienen que cumplirse a la vez (AND, nunca OR):

• Método — cualquier cosa distinta de "Cualquiera" limita la regla a ese verbo.
• Condición de header (opcional) — un nombre de header más está presente / está ausente / es igual a / contiene / coincide con regex.
• Condición de body — Contiene / Es igual a / Regex sobre el body de la petición saliente. (Los wildcards están disponibles para el patrón de URL y el de iniciador, pero aquí no.)
• Dominio iniciador (opcional) — el host de la página que hace la petición, no el destino, con los mismos cuatro tipos de match que el patrón de URL.
• Fijada a una pestaña (📌 en el popup) — la regla solo se aplica a las peticiones de esa pestaña concreta.

Encontrar una regla entre doscientas

Encima del listado hay cuatro mandos, y se combinan entre sí: lo que queda es lo que cumple todas las condiciones a la vez.

• El buscador. La caja dice "nombre, URL o grupo", pero además mira dentro de la Descripción y de las Etiquetas. Es el mismo criterio que el buscador del popup, a propósito: buscar "staging" tiene que encontrar la misma regla en los dos sitios.
• Filtro por tipo — solo los mocks, solo las redirecciones…
• Filtro por grupo. Además de los grupos que tengas, ofrece Sin grupo asignado, que es donde acaba todo lo que se crea deprisa. Solo aparece si tienes algún grupo.
• Filtro por escenario. Puedes elegir un escenario entero (cualquier variante de este escenario) o una variante concreta, y también Fuera de todo escenario: las reglas que ninguna variante gobierna. Ahí caen además las reglas que apuntan a una variante que aquí ya no existe —típico de un fichero importado de otra máquina—, que no se aplicarán nunca; el listado las marca con ⚠. Solo aparece si tienes algún escenario con variantes.

A cada regla se le ve el grupo al principio de su fila, en una etiqueta antes del nombre. Si el grupo está desactivado lleva un ⚠ y la fila sale atenuada. Las reglas sin grupo no llevan ninguna etiqueta: para encontrarlas, el filtro.

Lo que hay que tener en cuenta al filtrar. El orden del listado es el orden de prioridad (gana la de más abajo), y filtrar no lo cambia: lo que queda sigue en su orden real. Pero una regla que el filtro esconde sigue compitiendo, así que con un filtro puesto "la última que veo" no es necesariamente "la que gana". Por eso, en cuanto un filtro esconde reglas, encima del listado aparece una línea diciendo cuántas se ven de cuántas y recordándolo — con un botón para quitar los cuatro mandos de golpe. Si estás decidiendo prioridades con las flechas ↑ y ↓, quita los filtros antes.

Actuar sobre lo que el filtro enseña

Junto al buscador y a los tres filtros hay dos botones más, Marcar todo y Desmarcar todo, y actúan sobre lo que el filtro esté enseñando: con un filtro puesto, solo sobre esas reglas; sin filtro, sobre todas. El ☑ de cada grupo, en el panel Grupos, respeta el filtro igual. Una línea debajo de los dos botones lo dice con todas las letras, en vez de dejarlo en un tooltip —que no existe si tocas la pantalla, y que no aparece si llegas al botón con el tabulador—.

La selección sobrevive a cambiar de filtro, a propósito: buscar, marcar, buscar otra cosa, marcar más y actuar sobre la suma es justo para lo que sirven esos botones. Por eso el contador de la barra de selección lleva denominador y además dice lo que no estás viendo — «30 de 200 seleccionadas · 30 fuera del filtro»—, y por eso al borrar la confirmación dice cuántas van a quedar: «¿Borrar 30 de las 200 reglas? Quedarán 170.» Un número solo se puede leer de dos maneras opuestas ("creía que eran todas", "creía que eran solo las de la pantalla") y la resta cierra las dos. El ✕ de la barra cancela la selección entera, que es en lo que se diferencia de Desmarcar todo.

Cuando varias reglas coinciden con la misma petición

Nada impide que dos reglas coincidan con la misma petición, y cuando pasa se aplican todas, no solo la primera. Eso es lo que permite redirigir una llamada y añadirle una cabecera, sin tener que meter las dos cosas en una sola regla.

Se aplican en el orden de la lista, de arriba abajo, y cada regla solo opina sobre la parte de la petición de la que va su tipo: una de headers aporta cambios de cabecera, un mock aporta la respuesta, y cualquiera de ellas puede aportar además una latencia. Cuando dos reglas hablan de lo mismo, gana la que está más abajo en la lista. O sea que el orden de la lista de reglas es la prioridad — con los botones ↑ y ↓ de cada regla la mueves por encima o por debajo de otra, y eso cambia de verdad lo que acaba haciendo tu petición.

Hay dos combinaciones que no las decide el orden de la lista, sino una regla propia:

• Cancelar gana siempre. Si alguna de las reglas que coinciden es un Cancelar petición, la petición falla — esté donde esté en la lista, y digan lo que digan las demás. Una cancelación más un mock es una petición fallida, nunca una mockeada; y si además hay una latencia de por medio, el fallo simplemente llega tarde. Esa es la respuesta a "tengo una regla que cancela y otra que responde, ¿por qué se cancela?": quita de en medio la cancelación (desactívala, o afina su patrón) si lo que quieres es el mock.
• A un mock no le afecta nada de lo que actúa en la vuelta. Una petición mockeada no llega a la red, así que no hay respuesta real sobre la que pueda actuar una regla Modificar el body de la respuesta real —ni el lado de respuesta de una regla Modificar headers— aunque coincidan con esa misma petición. Escribe lo que quieras directamente en el body y en los headers del propio mock.

Para ver qué reglas gobernaron una petición concreta en vez de deducirlo, graba la pestaña y abre la lista de capturas: una petición que coincidió con tres reglas sale con una línea ⚡ por cada una, y la chapa del icono cuenta reglas aplicadas, no peticiones.

Proyectos: trabajos separados que no se mezclan

Un proyecto es todo lo que tienes montado para un trabajo: sus reglas, sus grupos, sus escenarios, sus variables y sus entornos. Y lo importante no es que estén juntos, sino que solo se aplica el proyecto activo: las reglas de los demás no tocan ni una petición, aunque estén encendidas.

Desde que instalas la extensión ya hay uno, y mientras sea el único no tienes que hacer nada: el nombre aparece arriba, al lado del título de la página, y ahí está todo lo tuyo. Al pulsarlo se abre el menú para cambiar de proyecto, crear otro, renombrarlo o borrarlo. En el popup aparece un desplegable Proyecto en cuanto haya más de uno.

Todo lo que creas cae en el proyecto activo, incluido lo que importas: un pack, una spec de OpenAPI, una colección de Postman o un HAR entran donde estés trabajando.

Y lo que exportas es el proyecto en el que estás, solo eso: sus reglas, sus grupos, sus escenarios, sus variables y sus entornos. Lo de los demás proyectos no viaja en el fichero.

El pack dice de qué proyecto salió (su nombre y su alcance), y al importarlo puedes elegir dónde entra: en el proyecto en el que estás, o en uno con ese nombre — se crea si no lo tienes, y si ya lo tienes, lo que importas se añade a lo que ya hubiera. Así es como se lleva un cliente de una máquina a otra de una pieza. El destino siempre empieza en «este proyecto»: crear uno es una decisión tuya, nunca un efecto secundario. Si el pack salió del proyecto principal —el que no tiene nombre propio— no te preguntará nada, porque no hay ningún nombre que ofrecerte.

Lo que también es de cada proyecto, y suele sorprender la primera vez:

• El alcance (dónde se le permite actuar a la extensión). Un proyecto puede estar limitado a localhost y otro actuar en todas partes. Uno nuevo nace sin restricción, y no hereda la del anterior.
• El entorno activo: cambiar de proyecto puede cambiar qué valores tienen tus variables.
• La papelera y la actividad. Lo que borras en un proyecto se recupera desde ese proyecto, y el tráfico grabado se queda donde lo grabaste. Vaciar cualquiera de las dos vacía la del proyecto que estás viendo, no la de todos.

Y una pista para cuando algo no se aplica: si una regla que juras haber creado no aparece por ninguna parte, mira el nombre de arriba. Casi siempre está en el otro proyecto. Es el primer sitio donde mirar, antes incluso de los de Por qué una regla puede no estar aplicándose.

Usar variables

Define un par nombre/valor una vez (botón "{{ }} Variables" en la página de opciones) y reutilízalo como {{nombre}} en cualquier sitio donde repetirías la misma cadena: el body de una regla, el valor de un header, una URL de redirección, el valor de un query param, el texto de reemplazo de una regla "Reemplazar texto en la URL", y tanto el texto de reemplazo como el valor nuevo del campo JSON de una regla "Modificar el body de la respuesta real".

Un nombre que no coincide con ninguna variable definida se deja tal cual está escrito — {{typo}} aparece literalmente en la petición o respuesta, en vez de desaparecer en silencio, así que un error es evidente en vez de un misterio. Las variables no se sustituyen en los campos de matching de una regla (el patrón de URL, o una condición de header/body/iniciador) — esos comparan contra la petición real, así que una variable ahí no significaría nada.

Ver y copiar lo que lleva dentro un JWT

Cuando el valor de una variable tiene forma de JWT, aparece una insignia JWT al lado. Al pulsarla se abre el visor: la cabecera y los claims, con la fecha de caducidad en horas de reloj y no en el número de segundos que trae dentro.

El visor trae dos botones, y hacen cosas distintas a propósito: Copiar token copia el token tal cual, listo para pegar en una cabecera Authorization; Copiar claims copia el JSON de la cabecera y el payload, que es lo que se pega en un ticket o en un chat.

El visor no comprueba la firma, y no puede: eso exige la clave del servidor. Sirve para leer lo que el token dice, no para saber si el servidor lo va a aceptar.

Entornos

Un entorno (botón "🌐 Entornos", junto a Variables) es un conjunto con nombre de sobrescrituras sobre tus variables — Local, Staging, Prod, lo que necesites. Solo hace falta que sobrescriba lo que realmente cambia entre entornos; lo que no menciona conserva el valor propio de la variable.

Elige el entorno activo con el botón de estrella junto a él en la página de opciones, o desde el desplegable Entorno del popup (solo aparece cuando existe al menos un entorno). Sin entorno activo, cada variable usa simplemente su propio valor base — igual que antes de que existieran los entornos.

Escenarios: varias versiones de la misma API

Un escenario agrupa varias variantes con nombre de la misma API, de las que solo una está activa: Login → Éxito / Credenciales inválidas / Backend caído. Cada regla puede pertenecer a una variante, y las reglas de una variante que no está activa no se aplican — el motor ni siquiera las mira.

La exclusión es por API, no global. Dos escenarios pueden estar en estados distintos a la vez: el de Login en "Backend caído" mientras el de Pagos sigue en "Éxito". Es la diferencia con tener las reglas sueltas y ir encendiéndolas y apagándolas a mano, que es lo que esto viene a sustituir.

Se crean y se organizan en la página de opciones, con el botón 🎭 Escenarios; se cambia la variante activa desde ahí o, más cómodo mientras pruebas, desde el popup, que enseña una fila por escenario. Una regla se asigna a una variante desde su propio formulario.

Si no quieres empezar de cero, + Desde plantilla deja el escenario montado con sus variantes y sus reglas ya escritas — los errores HTTP típicos, o el esqueleto de una colección REST. Y los escenarios viajan en el fichero de export junto a las reglas, así que se comparten con el equipo como todo lo demás; al importar, uno que choque con otro que ya tengas te pregunta si sobrescribir, duplicar u omitir, igual que las reglas y los grupos.

Elegir una variante que ya no existe —porque alguien la borró— guarda "a ninguna", no un puntero muerto: la regla deja de pertenecer a nadie y se comporta como una regla suelta.

Borrar un escenario, o una sola variante, te pregunta qué hacer con sus reglas en vez de decidirlo por ti. El diálogo dice cuántas viven dentro y ofrece dos salidas: Conservar las reglas, desactivadas —salen de su variante y quedan apagadas, así que ninguna empieza a aplicarse sola por haber dejado de estar gobernada— o borrarlas también, que no tiene vuelta atrás. Si dentro no hay ninguna regla, la pregunta es la corta de siempre. Es el mismo trato que ya recibía borrar un Grupo con reglas dentro.

Escribir una variable desde una respuesta

Al revés que todo lo anterior: en vez de meter un valor en una petición, una regla puede sacar un valor de la respuesta y guardarlo en una de tus variables. A partir de ahí esa variable ya se interpola sola en todos los sitios de la sección anterior, así que el caso típico se resuelve entero con una sola regla: extrae token de la respuesta de tu /login a la variable JWT y todas las reglas que mandan Authorization: Bearer {{JWT}} empiezan a mandar el token recién emitido, sin copiarlo a mano nunca más.

Está en el bloque plegable "Escribir una variable desde la respuesta" del formulario de la regla, y no hace nada hasta que eliges una variable: ninguna de tus reglas actuales captura nada. Puedes localizar el valor de dos formas:

• Un campo JSON, por su ruta con puntos — la misma forma que "Sobrescribir campo JSON". data.token lee el token de {"data":{"token":"…"}}.
• Una expresión regular, cuando la respuesta no es JSON o el valor está dentro de otra cosa. Se guarda el primer grupo de captura; si el patrón no tiene ninguno, la coincidencia entera.

Dónde acaba el valor, que es lo que conviene saber antes de usarlo: en la memoria de la sesión del navegador. No se escribe en disco, no sale en ningún fichero exportado —y no hay ninguna casilla para incluirlo— y desaparece al cerrar el navegador. Al abrirlo otra vez la variable vuelve a valer lo que ponga en tu lista de variables (normalmente, nada) hasta que una respuesta vuelva a rellenarla: volver a hacer login basta. El botón "Borrar valores capturados", en el panel de Variables, los tira en el acto sin esperar a cerrar nada.

El valor capturado gana al que tengas escrito en la lista y al de un entorno, pero solo dentro del entorno en el que se capturó: un token que sacaste en "Staging" no se usa al cambiar a "Producción", donde la variable vuelve a su valor de siempre.

Una limitación que hay que tener presente: el valor no está disponible para las peticiones que salgan en ese mismo instante. Pasa antes por el segundo plano de la extensión — son milisegundos, y el caso normal (login, y después el resto de llamadas) ni lo nota; el que sí lo nota es disparar dos peticiones a la vez y esperar que la segunda ya lleve el token de la primera.

Si la extracción falla no pasa nada malo: la respuesta llega a la página entera y sin tocar, y el panel de Actividad marca esa petición diciendo cuál de las dos cosas pasó — que ahí no había nada que extraer (la ruta o el patrón no encontraron nada en esa respuesta), o que no se pudo extraer (el cuerpo no es JSON, la expresión regular no es válida, el campo existe pero es un objeto). Los cuerpos binarios y los que se mantienen abiertos (streaming) no se leen nunca, y también se dice.

Por qué una regla puede no estar aplicándose

Primero, una comprobación rápida que ahorra mucho tiempo: el icono de la extensión en la barra lleva una chapa con el número de reglas aplicadas en la pestaña actual. Si está vacía después de recargar, no ha coincidido nada y la lista de abajo es donde mirar. Si está contando, la regla sí se aplica y la sorpresa está en lo que hace, no en si se ejecuta.

Y un atajo para la mitad de esta lista. Abre la regla y pega la petición en URL de prueba: además de decirte si el patrón coincide, la caja enumera lo que impediría que esa regla actuara —el interruptor maestro, el suyo propio, su grupo, su variante de escenario, un tipo de regla que el motor ya no aplica— y por separado lo que no puede decidir desde una URL: el método, las condiciones de header, body e iniciador, el alcance y la pestaña a la que esté fijada. Cuando hay algo que explicar, la caja termina diciendo qué se le escapa, que son justamente los últimos de esta lista.

Revisa esto en orden — cubre todos los motivos por los que una regla puede fallar en silencio:

1. El interruptor maestro (Activa arriba del popup, Extensión activa en la página de opciones) está apagado. Nada se aplica mientras lo esté.
2. El interruptor propio de la regla está apagado.
3. La regla pertenece a un grupo desactivado. Un grupo desactivado apaga en silencio todas las reglas de dentro — en el listado, esas reglas muestran un ⚠ junto al nombre del grupo.
4. La regla está fijada a una pestaña concreta (📌) y estás probando desde otra.
5. Este sitio está fuera del alcance configurado. Es el que más despista, porque no depende de la regla: si en Alcance (página de opciones) has elegido «Solo localhost» o «Solo estos dominios», en los demás sitios ninguna regla se aplica. El icono de la extensión lo dice — pasa el ratón por encima y verás «fuera de alcance aquí»—, y en ese modo el popup también lo avisa. Ojo con el caso de la lista vacía: «Solo estos dominios» sin ningún dominio escrito no permite nada, en ninguna parte.
6. El método HTTP de la petición no coincide con el Método configurado en la regla (si no está en "Cualquiera").
7. El patrón de URL/host no coincide de verdad — revisa el tipo de match tanto como el patrón en sí, y pega la URL real en URL de prueba (opcional) para salir de dudas. Si es Regex, una errata que deja el patrón inválido hace que la regla no coincida con nada en vez de dar un error — la caja de prueba avisa expresamente de ese caso. Otro clásico: escribir * o ? en un patrón que sigue en "Contiene" o "Es igual a", donde son caracteres literales — solo significan algo en modo Wildcard.
8. La regla tiene un patrón de exclusión que casa con esta URL. Es el motivo más fácil de pasar por alto, porque el patrón positivo sí coincide y todo parece correcto: mira Excepto URLs que contengan dentro de Coincidencia avanzada — el bloque se abre solo cuando la regla trae alguna, y el resumen plegado dice cuántas hay. Pegar la URL en URL de prueba (opcional) lo resuelve en el acto: dice cuál de las líneas la excluye.
9. La regla tiene una Condición de header, una Condición de body o un Dominio iniciador y la petición actual no los cumple. Para condiciones de header y de body en peticiones XHR en concreto: una regla de redirección/query params/reemplazo en la URL nunca puede activarse por ninguna de las dos, porque la URL se decide antes de que la página haya puesto sus headers o haya llamado a send(body) — esto solo funciona para los tipos "mock", "cancelar", "sin cambios", "modificar body de la petición" y "modificar headers" en XHR (en fetch funciona para todos los tipos). Una condición de body además solo compara contenido de texto (JSON, form-encoded, texto plano) — los bodies FormData/Blob/binarios nunca se leen para esto.
10. La petición no es fetch ni XMLHttpRequest. Net Tinker solo puede interceptar esas dos — no puede afectar a <img>, <script src>, CSS, fuentes ni ningún otro tipo de recurso a la hora de aplicar una regla (el panel de captura de DevTools sí puede verlos todos, simplemente no puede actuar sobre ellos). Cuidado con la lectura al revés: lo que cuenta es cómo se pidió, no qué se descargó. Un SVG o un PNG traídos con fetch() son fetch y sí se pueden mockear.
11. La petición no la ha lanzado la página, sino su service worker. Muchos sitios registran un service worker (lo verás en DevTools → Application → Service Workers) que descarga por su cuenta parte del contenido. Esas peticiones parecen normales — el navegador las cuenta como fetch y salen en la pestaña Network igual que las demás — pero Net Tinker trabaja desde dentro de la página, y un service worker es un sitio aparte al que ninguna extensión de este tipo llega. Una regla sobre esa URL se crea, se ve activa y no se dispara nunca. No tiene arreglo: es cómo funciona el navegador, no un fallo. El panel de DevTools sí sabe reconocerlas y te lo dice antes de que pierdas la tarde. Lo mismo vale para lo que pidan los workers de la página, para navigator.sendBeacon, para los WebSocket y para las precargas que resuelve el navegador solo.
12. La petición no ha llegado a ocurrir, porque el navegador la ha resuelto desde su propia caché. No hay nada que interceptar, y se parece exactamente a una regla que no funciona. Usa ↻ Recargar sin caché en el popup para recargar esa pestaña ignorando la caché, o añade una regla Modificar headers con el preset Bypass de caché para que pase en todas las recargas.
13. Otra regla que también coincide la está pisando. Las reglas no se tapan entre ellas —se aplican todas—, pero cuando dos hablan de lo mismo gana la que está más abajo en la lista, y una regla Cancelar petición gana a todo. Así que la regla puede estar aplicándose perfectamente y aun así no dejar rastro: reordena la lista, o afina el patrón de la otra regla. Ver Cuando varias reglas coinciden con la misma petición.
14. La regla tiene un tipo que esta versión no sabe aplicar. Puede pasar al importar un fichero escrito por una versión posterior, o si una actualización dejó una regla a medio migrar. Se ignora solo esa regla, exactamente como si no hubiera coincidido —nunca se responde con un mock vacío, y cualquier otra regla que coincidiera con esa misma petición sí se aplica— y la fila se marca en la lista de capturas con ⚠ y el nombre del tipo no reconocido, para que la situación se vea en vez de parecer tráfico normal. Abre la regla y vuelve a elegirle un tipo.
15. Una regla Modificar el body de la respuesta real sí coincidió, pero la respuesta era un stream en vivo que no se puede bufferizar, así que se dejó intacta a propósito. Ver Cosas que parecen fallos y no lo son; la lista de capturas lo dice con estas palabras: "coincide pero no se aplicó — respuesta en streaming".
16. Tienes dos copias de Net Tinker instaladas a la vez — lo normal es la de la Chrome Web Store más una de desarrollo cargada sin empaquetar. Las dos parchean la misma página, y la que responde primero se lleva la petición, así que la otra copia no ve nada: ni badge, ni línea en la lista de capturas, y la regla que estás mirando parece no hacer nada aunque sí se haya aplicado una. La pista es que la petición claramente se interceptó mientras la extensión que estás mirando no registra ninguna actividad. Desactiva una de las dos.

Ver qué ha pasado de verdad

Adivinar si una regla se ha aplicado es la vía lenta. Hay tres sitios que te lo dicen, y cada uno responde a una pregunta distinta:

• La chapa del icono — un contador en vivo de cuántas reglas se han aplicado en la pestaña actual. Mirarlo no cuesta nada y responde a "¿está pasando algo siquiera?".
• La lista de capturas — un registro guardado de peticiones, con la regla (o las reglas) que coincidieron con cada una. Es la que hay que abrir cuando algo va mal.
• El panel de DevTools — tráfico en vivo mientras trabajas, y el sitio desde el que crear reglas a partir de él. Ver Crear reglas a partir de tráfico real.

La lista de capturas está apagada hasta que la pides. Abre el popup en la pestaña que quieras observar y activa Grabar esta pestaña — solo se capturan las peticiones de esa pestaña. Después abre la lista con 📡 Capturas en la página de opciones (o Ver capturas desde el popup), que muestra el panel Peticiones capturadas.

Cada fila te dice, en este orden: la página, el status, la hora, y luego qué hizo Net Tinker con ella.

• Un ⚡ con un nombre de regla significa que esa petición coincidió con esa regla. Marca Solo aplicadas para esconder el resto, y usa el buscador para filtrar por URL o por nombre de regla. Cuando varias reglas gobiernan la misma petición, cada una sale en su propia línea ⚡, así que ver la misma URL repetida es la lista diciéndote exactamente qué reglas participaron.
• Toda fila con coincidencia dice además llegó a la red o no llegó a la red, que es la forma más rápida de confirmar que un mock es de verdad un mock.
• Un ⚠ significa que la regla coincidió pero no se pudo aplicar — un tipo de regla no reconocido, o una respuesta en streaming que una regla "Modificar el body de la respuesta real" tuvo que dejar en paz. Los dos casos están explicados en Por qué una regla puede no estar aplicándose.
• Ver regla abre la regla que se aplicó; Desactivar esta regla la apaga desde aquí; + Regla crea una regla nueva a partir de esa petición; y pinchando en la fila se abre el Detalle de la petición completo, con los headers y qué se cambió exactamente.

A diferencia del panel de DevTools, estas capturas sí se guardan, así que siguen ahí después de cerrar la pestaña o el navegador. La lista conserva las 200 más recientes y Vaciar la limpia. La grabación se detiene sola si cierras la pestaña que estabas grabando.

La papelera: deshacer un borrado

La 🗑 Papelera guarda tus últimos borrados para que puedas devolverlos. Lo que deshace es el gesto, no el elemento: borrar doscientas reglas sobre un filtro es una entrada, y restaurarla devuelve las doscientas de golpe. Es también lo que hace que borrar un grupo o un escenario con sus reglas dentro vuelva entero — las reglas y su contenedor entraron juntos.

Están todas las formas de borrar, y cada fila dice cuál fue:

• Regla borrada / Reglas borradas — una regla, o una selección.
• Grupo borrado / Escenario borrado / Variante borrada — con las reglas que hubiera dentro.
• Variable borrada / Entorno borrado.
• Reemplazado al importar — importar con Reemplazar lo que hay se lleva por delante las reglas, los grupos, los escenarios, las variables y los entornos del proyecto en el que estás —los demás no se tocan—, y esa barrida entera es una sola entrada.

Guarda los diez últimos borrados, y como mucho 1 MB en total. Los viejos van cayendo según entran los nuevos — no caduca por días, y es a propósito: el proceso de fondo de una extensión se para a los segundos de no hacer nada, así que una papelera que se vaciara «a la semana» se vaciaría de verdad la próxima vez que abrieras el navegador. Contar borrados no necesita reloj.

El tope de 1 MB está porque diez borrados de una regla no pesan nada y diez de doscientas reglas con cuerpos de mock dentro sí. Y un borrado que por sí solo no cabe no se guarda: la extensión lo dice antes de borrar, para que puedas exportar primero. Un deshacer que la gente cree tener y no tiene es peor que no ofrecerlo.

Dos cosas que restaurar no hace en silencio, y te avisa cuando pasa cualquiera de las dos:

• Una regla cuyo grupo ya no existe vuelve sin grupo. El grupo no se recrea: lo borraste después y a propósito, y devolverlo sería deshacer un gesto que no pediste deshacer.
• Una regla cuya variante de escenario ya no existe vuelve APAGADA. Estaba dormida porque su variante no era la activa; encenderla al volver sería aplicar una regla que no habías elegido aplicar.

La papelera es por proyecto: enseña lo que has borrado en el proyecto en el que estás, y lo que borraste en otro te espera en ese otro. Borrar un proyecto no pasa por la papelera — se lleva sus reglas, grupos, escenarios, variables, entornos, capturas y su propia papelera, y no hay vuelta atrás. Lo dice la confirmación, que además enumera lo que vas a perder.

Cosas que parecen fallos y no lo son

Net Tinker funciona parcheando fetch/XMLHttpRequest dentro del propio JavaScript de la página. Ese enfoque trae algunos efectos secundarios inevitables:

• Una petición cuyo cuerpo nadie lee no aparece en el panel de DevTools. Ni en la pestaña Network de Chrome, y no es cosa de la extensión: una respuesta cuyo cuerpo no se consume no termina, así que el navegador no dispara nunca el evento del que se alimentan las dos listas. Un código como const r = await fetch(url); log(r.status); —mirar el estado y no tocar el cuerpo— produce peticiones que llegan al servidor, vuelven bien y no salen en ningún sitio. Si tu página hace eso y parece que una regla no funciona, mira en 📡 Capturas: la extensión apunta lo que le hizo a la petición, la dé el navegador por terminada o no.
• Añadir un header de petición puede provocar un error de CORS. Si el header añadido no está permitido por la política CORS del servidor en una llamada cross-origin, el navegador bloquea la petición — esto ocurre en la capa CORS del propio navegador, por debajo de lo que Net Tinker puede controlar.
• El preset "CORS de desarrollo" no levanta un bloqueo real de CORS. El navegador hace su comprobación de CORS sobre la respuesta que mandó el servidor de verdad, antes de que Net Tinker llegue a tocar los headers de respuesta. Los valores permisivos que escribe el preset solo los ve el código de la página. Sirve para probar cómo se comporta tu código con esos headers; no para saltarse un servidor que no los envía.
• Los headers de respuesta que añade una regla no aparecen en la pestaña Network de DevTools. Esa pestaña muestra los bytes reales que llegaron por la red; los cambios del lado de respuesta de una regla "Modificar headers" se aplican después, solo sobre el objeto que lee el JavaScript de la página. Son reales para la página — solo invisibles para esa vista concreta de DevTools.
• La columna "Iniciador" de DevTools muestra interceptor.js en todas las peticiones mientras haya alguna regla activa en la página, porque todas las peticiones pasan por el fetch/XMLHttpRequest parcheado de Net Tinker antes de llegar (o no) a la red. No afecta al funcionamiento, solo a la atribución. Si te molesta, añade interceptor.js a la Ignore List de DevTools (Settings → Ignore List) — así DevTools ignora esos frames al calcular el iniciador.
• Una regla fijada a una pestaña que ya has cerrado no vuelve a dispararse. El id de una pestaña no significa nada una vez esa pestaña desaparece, así que la regla queda inerte para siempre — y volver a abrir la misma página da una pestaña nueva con un id nuevo, que no la recupera. No hace falta la pestaña original: la página de opciones marca esas reglas con 📌 y ofrece un botón 📌✕ que quita la restricción.
• Una regla "Modificar el body de la respuesta real" no hace nada en un XHR con responseType binario. El body solo se puede transformar si responseType es "", "text" o "json"; con "blob", "arraybuffer" o "document" no hay forma de leerlo como texto, así que esa petición concreta vuelve intacta. La regla no está mal — simplemente ahí no puede actuar.
• "Sobrescribir un campo JSON" deja completamente en paz un body que no sea JSON. Lo mismo si la ruta con puntos no lleva a un objeto (por ejemplo user.status cuando user es un texto). El body se devuelve exactamente como llegó, en vez de quedar reescrito a medias o sustituido por una suposición. Para bodies que no son JSON, usa el modo "Buscar y reemplazar".
• "Modificar el body de la respuesta real" se salta las respuestas que son streams abiertos. Transformar un body obliga a leerlo entero primero, y un tipo de medio cuyo contrato entero es mantenerse abierto —text/event-stream (server-sent events), multipart/x-mixed-replace— no termina nunca. Esas respuestas se devuelven intactas, con su stream vivo, y la regla simplemente no se aplica a esa petición; la lista de capturas lo deja anotado como "coincide pero no se aplicó — respuesta en streaming", para que no sea un no-hacer-nada silencioso. El criterio es el tipo de medio, no el tamaño: una respuesta grande normal sí termina, así que se transforma con normalidad — solo que llega de golpe en vez de progresivamente. Las reglas de cualquier otro tipo no tocan el body de la respuesta y no tienen ninguno de los dos efectos.

Pegar un cURL para crear la regla

cURL es el formato en el que ya está todo: las DevTools de cualquier navegador tienen Copiar como cURL, la documentación de cualquier API pega ejemplos en cURL, y quien te reporta un fallo te manda un cURL. En el formulario de regla, junto al campo Patrón, el botón Pegar un cURL abre un cuadro donde pegarlo.

Un cURL describe una petición, no una respuesta, así que esto rellena con qué coincide la regla —la URL, el modo de comparación y el método— y la respuesta la escribes tú. El diálogo lo dice, y antes de aplicar nada te enseña lo que ha entendido.

• Entiende las dos variantes que copia Chrome: la de bash y la de cmd de Windows, que usa otro carácter de continuación y otras comillas. Pega la que te dé tu sistema.
• Deduce el método: un cURL con --data y sin -X es un POST.
• Si el comando trae algo que no se puede reproducir —un -F multipart, un -d @fichero— lo dice y no lo aplica a medias.
• Si lleva credenciales dentro (y un cURL copiado de unas DevTools casi siempre las lleva) el diálogo las nombra. No se guardan en ninguna parte: ni van a la regla, ni se pueden elegir como condición.

El cuerpo y las cabeceras, si tú quieres. Debajo del resumen, el diálogo pregunta qué más usar del cURL, y por defecto no usa nada:

• El cuerpo, como condición —la regla solo casa con peticiones que lleven exactamente ese cuerpo— o como el cuerpo que se envía: la regla pasa a Body petición con ese cuerpo, para que lo edites. Un cuerpo de varias líneas no puede ser condición, porque ese campo es de una sola línea, y el diálogo lo dice.
• Una cabecera como condición, a elegir entre las que trae: la regla solo casará con peticiones que la lleven con ese mismo valor. Una regla admite una, y un cURL de DevTools trae quince, así que eliges tú.

El patrón queda como la URL entera, en modo Es igual a. Si esa URL trae parámetros que cambian en cada llamada —un ?t=1725381000— el diálogo te avisa: recórtalos en el campo de patrón o la regla no volverá a coincidir.

Crear reglas a partir de tráfico real

Abre DevTools en cualquier página y busca la pestaña "Net Tinker" (junto a Elements, Console, Network, etc.). Lista todas las peticiones que hace la página mientras el panel está abierto — no solo fetch/XHR, todos los tipos de recurso — para que encuentres exactamente la llamada que te interesa. La cabecera muestra Capturando, y al pulsarla pasa a Pausado si prefieres congelar la lista; marca Conservar registro para que no se vacíe al navegar, y Vaciar la limpia.

1. Cada fila tiene un desplegable "+ Regla…" y un botón dedicado Mockear. Elegir un tipo abre el editor de reglas ya relleno con la URL real de esa petición (como match Es igual a, así que solo afecta a esa llamada exacta) y su método. El desplegable ofrece todos los tipos de regla menos el mock, que tiene su propio botón.
2. Una regla creada así llega desactivada salvo que sea un mock o una cancelación — esas dos están completas en cuanto se crean, mientras que el resto son esqueletos todavía vacíos, y activar una "redirección" o un "body de respuesta" vacíos rompería justo el endpoint que estás depurando. Rellénala y luego enciéndela. El panel te dice cuál de las dos cosas ha pasado cada vez.
3. Mockear va más allá: también copia el código de estado, los headers de respuesta y el body reales de esa petición a la nueva regla, así partes de lo que devolvió el servidor de verdad en vez de escribir un fixture a mano.
4. Una marca ⚡ junto a una fila significa que alguna de tus reglas activas ahora mismo interceptaría esa petición exacta — se evalúa en vivo contra tus reglas actuales, no contra las que hubiera activas cuando la petición ocurrió de verdad.
5. Cada fila también tiene una opción "Copiar como…" para copiar la petición como comando cURL o como fragmento fetch(), listo para pegar en una terminal o en la consola.
6. Exportar HAR guarda como fichero .har estándar las peticiones que se ven ahora mismo en la lista, para dárselas a otra persona o cargarlas en otra herramienta. El diálogo enumera los valores sensibles que ha encontrado y ofrece Sanear credenciales (siempre marcado al abrirse) e Incluir cuerpos de respuesta (siempre desmarcado, recortados a 1 MB cada uno, porque son lo que engorda el fichero). Las dos casillas se rearman cada vez que se abre, así que la opción segura nunca queda apagada de una exportación anterior. Un HAR lleva las cabeceras reales de la petición, Authorization incluida, además de las cookies — trata el fichero como una credencial.
7. Para una petición GraphQL (detectada automáticamente y mostrada como su nombre de operación junto a la URL), crear una regla desde ella también rellena una Condición de body exigiendo ese nombre de operación — porque un endpoint GraphQL sirve todas sus operaciones en la misma URL, y una regla que solo mirase la URL aplicaría a todas ellas. Puedes verlo y editarlo en la regla que se abre (es la misma condición de body de arriba, ya rellena por ti). El filtro del panel también busca por nombre de operación.
8. El panel lista todo lo que hace la página, pero no todo se puede mockear. Si creas una regla desde una fila que no lo es, el panel te avisa antes de que la des por buena: la regla se crea, pero nunca se disparará. Hay dos motivos distintos y te dice cuál es el tuyo:
   • Por cómo se pidió. Una imagen de un <img>, un <script src>, una hoja de estilos o una fuente no pasan por fetch/XMLHttpRequest, así que no hay nada que interceptar. Ojo: lo que cuenta es cómo se pidió y no qué se descargó — un SVG o un PNG traídos con fetch() sí se pueden mockear, y por eso siguen apareciendo en la lista.
   • Por quién la pidió. Si la lanzó el service worker del sitio y no la página, Net Tinker no llega ahí — y esta es la traicionera, porque la fila se ve idéntica a una normal. El panel nombra el script responsable para que puedas comprobarlo en Application → Service Workers.
   La casilla "Solo mockeables" (marcada de fábrica) esconde de un golpe las filas de los dos casos. Desmárcala para verlo todo: seguirás pudiendo copiarlas como cURL, compararlas y exportarlas a HAR, que eso sí funciona con cualquier petición.

Las capturas de este panel viven solo en memoria mientras DevTools está abierto — al cerrar DevTools se vacían, y no se guarda nada hasta que conviertes explícitamente una petición capturada en una regla o exportas un HAR. Esa es la diferencia con la lista de capturas de la página de opciones, que sí se guarda a propósito.

Peticiones repetidas, y cuánto tarda todo

Cuando la misma petición —mismo método y misma URL— sale varias veces seguidas, la fila lleva una insignia ×N. Es lo que convierte «esto va lento» en «esto se está pidiendo cuatro veces», que es otra conversación. La casilla Solo repetidas deja en la lista únicamente esas.

La cabecera del panel resume además los tiempos de lo capturado: P50, P90, P95 y P99 y la proporción de errores. Dos cosas que conviene saber para leerlo:

• No aparece con menos de cinco peticiones. Un P95 sobre tres muestras es un número con aire de estadística.
• Las peticiones que retrasa una regla tuya se quedan fuera, y el panel dice cuántas. Un percentil calculado sobre llamadas que llevan 1.000 ms puestos por ti no mide nada, y encima parece que sí.

Buscar dentro de los cuerpos

El buscador de la cabecera filtra por URL. El botón Buscar en los cuerpos repite esa misma búsqueda dentro de lo que viajó: útil cuando lo que recuerdas no es la ruta sino un identificador, un mensaje de error o el nombre de una operación de GraphQL.

Los cuerpos se piden al navegador uno a uno y solo cuando lo pides, así que sobre una lista larga tarda un momento. Es el mismo precio que pagar por ver un cuerpo, multiplicado por las filas.

Copiar una petición a otro formato

Cada fila tiene Copiar como…, y lo que copia depende de para qué lo quieras:

• cURL y fetch, para repetir la llamada desde un terminal o desde la consola.
• Playwright y Cypress, como mock para un test.
• Tipos de TypeScript, deducidos del cuerpo que volvió. Es un punto de partida, no un contrato: lo que no aparece en esa respuesta no puede adivinarse, y lo dice el propio fragmento.
• Informe de defecto, en Markdown, con la petición, la respuesta, la regla que actuó si la hubo, y la versión del navegador y de la extensión. Va saneado: es lo único de esta lista cuyo destino es un ticket compartido.

Comparar dos respuestas

El botón ⇄ de una fila la fija, y el de otra abre la comparación. No se lanza ninguna petición: se comparan dos capturas que ya tienes.

Los cuerpos JSON se comparan por campos y no por líneas, así que el orden de las claves no produce diferencias, y las coincidencias se cuentan en vez de listarse. Dos mandos, en el propio diálogo:

• Ignorar estos campos. Escribe los nombres que cambian en cada llamada por diseño —timestamp, requestId, traceId, Date— y desaparecen de la comparación. Vale por nombre de campo (también dentro de las listas) o por ruta entera, como $.data.total. Siempre dice cuántas ha escondido: nada se quita en silencio.
• Tapar datos personales. Sustituye correos, teléfonos, IBAN, tarjetas y DNI por una marca que dice de qué clase era el dato. Nace desmarcada en cada comparación, y es a propósito: aquí tapar de más borra justo el campo que habías ido a mirar.

Los tokens que aparecen sueltos dentro de un texto (un JWT, una clave de proveedor) se tapan siempre, sin depender de esa casilla. La asimetría es deliberada: ahí no hay falsos positivos que perder y sí un secreto que enseñar.

Partir de una spec de OpenAPI / Swagger

Si la API que estás mockeando publica su spec, no hace falta escribir las veinte reglas a mano. Pulsa Importar y elige el openapi.json (o el swagger.json): cada endpoint, método y código de respuesta se convierte en una regla con su patrón de URL, su estado y su cuerpo ya rellenos. Es el mismo botón con el que importas tus propios ficheros, una colección de Postman o un perfil de ModHeader: la spec se reconoce sola por su sello de versión, y la flecha ▾ de al lado enumera todo lo que el botón acepta.

Qué se soporta

• OpenAPI 3.0, OpenAPI 3.1 y Swagger 2.0. Cualquier otra versión se rechaza diciendo cuál es, para que sepas qué tienes delante.
• Solo JSON. Si tu spec está en YAML, conviértela antes: en Swagger Editor es File → Convert to JSON, y desde una terminal npx js-yaml api.yaml > api.json. Leer YAML obligaría a incluir un parser de YAML, y esta extensión no lleva ni una línea de código de terceros. Aun así puedes elegir el .yaml: te lo dirá con esas mismas palabras en vez de quejarse de un JSON roto.

De dónde sale el cuerpo de cada mock

En este orden, y el orden importa:

1. el example que la spec da para esa respuesta;
2. el primero de sus examples con nombre (los demás se listan como no importados, uno a uno);
3. el example del esquema;
4. un esqueleto generado a partir del esquema: la forma correcta con valores de relleno ("string", 0, true), salvo en los formatos que tu código sí parsea (fechas, UUID, correos), que llevan un valor plausible para que no revienten al llegar.

Ese último no es un dato de la API: se lo inventa esta extensión. Toda regla con un cuerpo generado lo dice en su propia descripción, para que dentro de tres semanas se siga distinguiendo. Edítalo y dale datos realistas antes de fiarte de lo que veas en pantalla.

Cómo queda organizado

• Todo cae en un solo grupo con el nombre de la API, así que puedes apagar la importación entera de un clic.
• Los tags de la spec se convierten en las etiquetas de las reglas, y por ahí puedes filtrar en la lista.
• Un endpoint que declara varios códigos de respuesta se convierte en un escenario con una variante por código —200 / 404 / 500— y se deja activa la primera correcta, así que cambiar ese endpoint entre "funciona" y "falla" es un clic. Un endpoint con una sola respuesta se queda como una regla normal.
• Todas las reglas importadas llegan desactivadas. Una spec puede producir decenas de golpe, y encenderlas todas dejaría tu aplicación contestando mocks en cada endpoint antes de que hayas elegido ninguno.

Elegir qué endpoints entran

No se crea nada hasta que tú lo digas, y no es todo o nada. Primero sale un diálogo con lo que trae la spec —el mismo que sale con una colección de Postman, para que la pregunta no se conteste distinto según el fichero—: una fila por endpoint, con su método, la URL contra la que va a casar y cuántas reglas y variantes crearía — más un buscador, marcar todo / desmarcar todo sobre lo que el buscador esté enseñando, y un contador que dice a cada momento qué suma lo que llevas marcado. Las filas salen agrupadas por los tags de la spec, en el orden en que ella los declara, y el tag va escrito en la fila para que el buscador lo encuentre: en una spec de 300 endpoints, escribir un tag y pulsar marcar todo trae ese recurso y nada más.

Todo nace marcado, porque importar no destruye nada —llega todo desactivado— y "solo este endpoint" está a tres gestos. Lo que no marques no llega a crearse: la spec se recorre dos veces, y la primera solo lee y cuenta. Esto no es "impórtalo todo y borra el resto".

Qué te dice que no ha podido hacer

Cuando continúas, el diálogo de importar lista las cosas que no han sobrevivido a la traducción, con su motivo: $ref que apuntan a otro fichero, esquemas que se referencian a sí mismos, alternativas oneOf de las que solo se ha usado la primera, respuestas declaradas como default o 4XX (no hay un código de estado concreto que poner, y elegir uno sería inventarse la respuesta), formatos como image/png o text/csv para los que no se puede fabricar un cuerpo, y cabeceras de respuesta que declaran un tipo en lugar de un valor. Todo lo que se refiere a una respuesta concreta va además escrito en la descripción de su regla, así que sigue ahí cuando cierras el diálogo.

Reimportar una versión más nueva de la misma spec es seguro: las reglas se reconocen como ya existentes (mismo tipo, método y patrón) y eliges si sobrescribir, duplicar u omitir, igual que en cualquier otra importación. Un diff campo por campo que conserve tus ediciones locales todavía no existe.

Qué ha cambiado desde la última vez

Al importar algo que ya habías importado —la misma spec una versión después, el pack del equipo, una colección de Postman— el diálogo añade un resumen de qué ha cambiado respecto a las reglas que ya tienes:

• Cuántas son nuevas y cuántas siguen igual.
• Cuáles han cambiado de forma, con los campos por su nombre: ahora trae fechaAlta, ya no trae estado. Se compara la forma y no el texto, así que editar el cuerpo del mock a mano no cuenta como cambio — solo cuenta que la API se haya movido.
• Cuáles se han quedado sin operación: reglas tuyas, en ese grupo, que ya no vienen en el fichero. Es lo único que no se puede ver mirando lo que importas. No se borra nada: se enseñan y decides tú.

No hace falta que la extensión haya guardado la spec anterior, y no la guarda: la comparación es entre lo que traes ahora y las reglas que tienes delante.

Traer una colección de Postman

Una colección de Postman entra por el mismo botón Importar y se reconoce sola por su sello, igual que una spec. Lo que se convierte en reglas no son las peticiones —esta extensión no envía nada, responde— sino los ejemplos de respuesta guardados que cada petición lleve dentro: cada uno tiene un código de estado, unas cabeceras y un cuerpo reales, y eso es un mock campo por campo. Al revés que con una spec, aquí no se genera ningún cuerpo: lo que veas en la regla es lo que el servidor contestó de verdad el día que se guardó el ejemplo.

Sin ejemplos guardados no sale nada, y ese es el caso más frecuente

Guardar un ejemplo es opcional en Postman y mucha gente no lo hace, así que es perfectamente posible importar una colección de doscientas peticiones y no obtener ni una regla. No es un fallo: no había ninguna respuesta que copiar. El arreglo está en Postman, no aquí — abre la petición, envíala, y usa Save Response → Save as example. Eso deja la respuesta real guardada dentro de la colección. Repítelo con cada petición que quieras mockear y vuelve a exportar la colección.

El importador lo cuenta con esas mismas palabras y de forma agregada —cuántas peticiones se han quedado sin nada, y unos cuantos nombres—, en vez de repetir la misma línea doscientas veces.

Varios ejemplos de una misma petición son un escenario

Es lo que hace que esto encaje tan bien: en Postman es habitual guardar varios ejemplos con nombre de la misma petición —"Success", "401 Unauthorized", "500"— y eso es literalmente un escenario, con una variante por ejemplo. Los nombres de las variantes son los que escribiste allí, así que la correspondencia no hay que inventarla, y se deja activa la primera respuesta 2xx. Con un solo ejemplo no se monta ningún escenario: la petición se queda como una regla suelta, porque un escenario de una variante es un contenedor de un elemento.

Cómo queda organizado

• Cada ejemplo guardado se convierte en una regla Mockear la respuesta (API) con el estado, el texto de estado, las cabeceras y el cuerpo del ejemplo.
• El nombre de la colección se convierte en un solo grupo, reutilizado por nombre al reimportar, así que puedes apagar la importación entera de un clic. Las carpetas de la colección van a las etiquetas de la regla, que es por donde se filtra.
• La URL de la petición se convierte en un patrón de tipo Regex anclado por el final, para que /users no acabe secuestrando además el tráfico de /users/42 —dos peticiones de la misma colección, importadas las dos—. Un parámetro de ruta (/:id) casa con cualquier valor, y se dice: la colección guarda el nombre del parámetro, no lo que la página va a enviar. Si la URL no queda absoluta, el patrón casa esa ruta en cualquier host, y eso también se avisa.
• La query string no forma parte del patrón, así que la regla también se aplica a la misma ruta sin esos parámetros. Se dice cuáles eran.
• Todo llega desactivado, igual que con una spec: una colección produce decenas de reglas de golpe y encenderlas todas dejaría tu aplicación contestando mocks en cada endpoint antes de que hayas elegido ninguno.
• Un export de entorno de Postman —el otro fichero, el que acaba en .postman_environment.json— entra por el mismo botón y produce tus variables más un entorno con sus valores. Al importar un segundo entorno (Dev y Prod, que es como se usa esto) la variable ya existe y se conserva tu valor: el segundo fichero solo aporta su capa.

Qué no se trae, y por qué

• El cuerpo de la petición, la autenticación y los scripts de pre-request y de test. Los tres describen lo que un cliente envía, o lo que ocurre antes de que llegue la respuesta, y aquí no se envía nada: se contesta. Se cuentan agregados, uno por colección, para que no entierren a los avisos que sí dicen algo distinto de una petición a otra.
• Las cookies del ejemplo, incluida la cabecera Set-Cookie. Una respuesta construida dentro de la página no puede poner cookies —el navegador descarta esa cabecera—, así que copiarla dejaría una regla prometiendo algo que no puede hacer.
• Las cabeceras que describen la conexión grabada y no la respuesta: Content-Length (mediría el cuerpo de entonces, no el que tengas ahora en la regla), Content-Encoding (el cuerpo del ejemplo está guardado ya descomprimido, así que declarar gzip haría que el cliente intentara inflar texto plano), Date —la fecha de la grabación— y las de salto a salto.
• Un ejemplo cuyo cuerpo se guardó en binario (una imagen, un PDF): la regla se crea con el cuerpo vacío y se avisa. Decodificarlo dejaría binario dentro de un campo de texto.
• Un ejemplo con un estado que no se puede fabricar: un 0, que es lo que Postman guarda cuando la petición no llegó a contestar, o un 1xx. Solo entra de 200 a 599.
• Un verbo que el formulario no sabe representar (PURGE, LINK): la regla se queda en "cualquier método" y se avisa de cuál era.

Todo lo que se refiere a un ejemplo concreto va además escrito en la descripción de su propia regla, así que sigue ahí cuando cierras el diálogo.

Las variables se resuelven al importar, y el vínculo se pierde

Es lo único de este importador que se puede dar por hecho que funciona de una manera y funciona de otra, así que va con su propio apartado. La sintaxis es la misma en los dos sitios ({{nombre}}), pero el patrón de una regla no se interpola nunca: se compara contra peticiones reales, así que un patrón con {{baseUrl}} dentro sería una regla muerta. Por eso las variables que aparecen en la URL se sustituyen por su valor en el momento de importar, con el valor que traiga la colección.

La consecuencia, que es lo que hay que retener: cambiar la variable después no mueve las reglas. El patrón ya no la menciona, así que apuntar la colección a otro entorno es editar esos patrones a mano. En los valores —el cuerpo y las cabeceras del mock— sí se conservan escritas como {{nombre}} y se siguen interpolando en cada petición, igual que cualquier variable de aquí.

Y dos cosas sobre los nombres:

• Aquí un nombre de variable solo puede llevar letras, dígitos y guiones bajos. Una llamada api-host no se importa —sería una fila muerta en el panel, porque nadie la sustituiría— pero sí se usa para resolver las URL, que es lo que evita dejar un comodín donde había un valor conocido. Se dice cuál era: renombrarla en el fichero y volver a importar es cosa de diez segundos, si sabes que hace falta.
• Las variables dinámicas de Postman ({{$randomInt}}, {{$guid}}, {{$timestamp}}) no existen aquí y no pueden existir: valen algo distinto en cada envío, y esto no envía. Esa parte de la URL pasa a casar con cualquier cosa, y se cuentan una a una.

Qué versiones se aceptan

• Collection v2.1 y v2.0. Para lo que se lee aquí son casi el mismo fichero: los ejemplos guardados, las carpetas y las variables son idénticos.
• Una colección v1 se rechaza por su nombre, no a mitad — y con la salida dentro del mensaje: impórtala en la propia app de Postman y vuelve a exportarla como Collection v2.1. Ese fichero sí entra. Cualquier otro sello se rechaza también diciendo cuál era, en vez de intentarlo y dejar media importación vacía.
• Una colección que no declara su formato se lee como v2.1 y se dice. Varias herramientas que generan colecciones omiten ese campo, y asumirlo en silencio es lo único que no se puede hacer.

Elegir qué peticiones entran

Antes de construir nada sale el mismo diálogo que con una spec: una fila por petición, con su método, la URL ya resuelta contra la que va a casar y cuánto crearía —sus reglas, y su escenario con sus variantes si trae varios ejemplos—, más un buscador, Marcar todo / Desmarcar todo sobre lo que el buscador esté enseñando, y un contador que dice a cada momento qué suma lo que llevas marcado. Lo que no marques no llega a crearse.

Las peticiones sin ningún ejemplo utilizable no salen en esa lista, porque no hay nada que elegir en ellas — pero siguen contando en el aviso de arriba, que es donde su ausencia importa.

Reimportar una versión más nueva de la misma colección es seguro: las reglas se reconocen como ya existentes (mismo tipo, método y patrón) y eliges si sobrescribir, duplicar u omitir, igual que en cualquier otra importación.

El viaje de vuelta no existe

No se puede exportar un escenario como colección de Postman, y no es un pendiente: una regla no es una petición. De los nueve tipos solo el mock se le parecería, y para "modificar headers" o "cancelar petición" es que Postman no tiene ningún concepto donde ponerlos. Además el patrón de una regla es una expresión regular, y de una expresión regular no se puede recuperar la URL que la originó: un exportador tendría que inventarse una, y esa URL inventada es justo la que alguien enviaría contra un servidor de verdad. Para llevarte un endpoint a otra herramienta está Copiar como… (cURL o fetch()), que trabaja sobre la URL que estás viendo de verdad.

Importar una captura HAR

Un HAR es tráfico que de verdad ocurrió: lo que se pidió, y lo que el servidor contestó, con su código, sus cabeceras y su cuerpo exactos. Se graba en la pestaña Red de DevTools (botón derecho → Save all as HAR) y entra por el mismo botón Importar, reconocido solo.

Para qué sirve de verdad, que es lo que lo distingue del panel de Actividad: para tráfico capturado en otra máquina. El panel solo ve lo que pasa por este navegador; un HAR llega por correo desde el portátil de quien reprodujo el fallo, desde la máquina de un cliente o desde una ejecución de CI. Cada petición se convierte en un mock con la respuesta que hubo aquel día.

Qué se importa y qué no:

• Solo lo que esta extensión puede tocar: fetch y XMLHttpRequest. Las imágenes, los estilos, las fuentes y el propio documento se quedan fuera, y el resumen dice cuántos eran.
• Una regla por método y URL, sin la query. Las URLs de un HAR vienen con lo que llevaban aquel día (?_=1725354722000, un token de paginación); un patrón exacto contra eso no volvería a coincidir nunca. Si necesitas distinguir dos llamadas que solo se diferencian en la query, el campo Patrón está ahí para volver a ponerla.
• Si la misma petición aparece varias veces —un polling, por ejemplo— se guarda la última respuesta, que es como acabó la sesión. La lista te dice cuántas capturas había.
• Las respuestas binarias y las de más de 512 KB se descartan: no se recortan, porque medio JSON es JSON roto y el fallo parecería del mock.
• Las peticiones que no llegaron a contestar (abortadas, caídas, bloqueadas) tampoco entran: no hay respuesta que copiar.

Las reglas nacen apagadas y dentro de un grupo con el nombre del host, para que puedas encender las que quieras —o borrarlas todas juntas— sin que la aplicación se ponga a contestar una sesión de ayer en cuanto acabas de importar.

Traer un perfil de ModHeader

ModHeader salió de las tiendas de Chrome y de Edge en julio de 2026, y mucha gente se quedó con sus perfiles exportados y sin nada que los leyera. Ese fichero entra por el mismo botón Importar y se reconoce solo: cada perfil se convierte en una regla Modificar headers, que es el tipo que cubre su caso central entero. Se acepta tanto el array de perfiles que escribe su exportador como un perfil suelto, porque su propio importador aceptaba las dos formas.

Qué se convierte en qué

• Un perfil se convierte en una regla, no en una por cabecera: doce cabeceras y un filtro de URL son conceptualmente una sola regla. El rótulo que le pusiste allí se queda como nombre de la regla —es por el que la vas a buscar— y su etiqueta corta, como etiqueta.
• Las cabeceras de petición y las de respuesta caben en la misma regla, así que un perfil que tocara las dos cosas no se parte en dos.
• Una cabecera con valor se convierte en Clave: Valor. Una cabecera con el valor vacío se convierte en -Clave, es decir, en borrarla: es lo que hacía ModHeader, salvo que la cabecera llevara marcado su send empty header.
• Su modo de añadir separando por coma se convierte en +Clave: Valor, que hace exactamente lo mismo.
• Su filtro de URL se convierte en el patrón de la regla, en modo Regex, porque allí eso ya era una expresión regular. Varios filtros se unen en una alternancia, que es como los evaluaba ModHeader: le bastaba con que acertara uno. Un perfil sin filtro de URL se aplicaba a todas las peticiones, y así se importa —con un patrón que casa con todo— diciéndolo.
• Su filtro de dominio iniciador se convierte en la condición de iniciador, anclada como sufijo de dominio para que example.com no case además con example.com.attacker.net.
• Sus exclusiones de URL se convierten en Excepto URLs que contengan, cuando se puede demostrar que significan lo mismo — ver abajo.
• Sus reemplazos de URL se convierten en una regla Reemplazar texto en la URL aparte, en el mismo grupo y compartiendo patrón, método, exclusiones e iniciador con la de cabeceras: una regla lleva un solo tipo, así que un perfil que además reescribía la URL necesita dos.
• Los comentarios que hubieras escrito en cada cabecera o en cada filtro van a la descripción de la regla, cada línea etiquetada con lo que identifica su entrada. Es texto tuyo, y una vez desinstalada la otra extensión no había de dónde recuperarlo.
• Todo cae en un solo grupo llamado ModHeader, reutilizado por nombre al reimportar, así que no se acumulan dos.

Las entradas que en ModHeader estuvieran desactivadas no se traen apagadas: para su propio motor una cabecera sin marcar no existía, así que traerla habría sido inventar una regla que allí no estaba.

Todo llega desactivado, y aquí importa más que en el resto

ModHeader aplicaba un perfil a la vez —el seleccionado, más los que tuvieras en always on—. Encender de golpe todo lo importado montaría a la vez combinaciones de cabeceras que nunca tuviste juntas; y un perfil que no filtraba por URL se convierte en una regla que casa con todo. Las dos cosas son exactamente "romper el sitio que estás depurando". Los perfiles que estaban en always on se señalan al importar como los primeros candidatos a encender, que es la información que separa "esto lo quiero activo ya" del resto del lote.

Qué no se convierte, y por qué

Todo lo de abajo se cuenta al importar, perfil a perfil y con su motivo:

• Una exclusión que sea una expresión regular de verdad. Aquí las exclusiones son texto literal, así que solo se traen las que se pueden demostrar equivalentes: un patrón sin metacaracteres sueltos, y la forma habitual .*/algo.*, que es exactamente "contiene /algo". Las demás se quedan fuera con su aviso — y es la única pérdida de este importador que hace que la regla dispare de más en vez de de menos, así que es la que conviene revisar primero.
• Un reemplazo de URL que sea una regex, o que use grupos de captura ($1): aquí el texto que se busca es literal, así que no habría grupos que referenciar y un $1 se escribiría crudo dentro de la URL.
• Su modo de añadir pegado, sin separador. Aquí se añade con coma, así que se convierte a lo que más se le parece y se avisa de qué cabecera es: conserva más que descartarla entera.
• Una restricción de métodos que no quepa en el único Método de una regla: se queda en "cualquiera" y se avisa.
• Lo que aquí no tiene equivalente: sus cabeceras de cookies, las de CSP, y sus filtros por pestaña, por grupo de pestañas, por ventana, por tipo de recurso y por hora.
• Cualquier campo que una versión de ModHeader posterior a esta haya añadido y que aquí no se conozca. Se avisa diciendo cuál era, que es lo que hace falta para arreglarlo a mano en vez de descubrirlo por su ausencia.

Un perfil del que no se pueda convertir nada —porque solo llevaba cosas de esa lista— no produce ninguna regla, y también se dice.

Al importar no se sanea nada, al revés que al exportar: un fichero exportado se comparte, pero uno importado son tus propios datos volviendo a tu máquina. Redactar aquí un Authorization no protegería a nadie y dejaría una regla que no funciona, sin ningún sitio de donde recuperar el valor.

Qué cubre (y qué no) "sanitizar al exportar"

Exportar escribe tus reglas y grupos en un fichero JSON, junto con tus variables y entornos. Exportarlo todo incluye todas las variables que tengas; exportar una selección de reglas incluye solo las variables que esas reglas referencian por nombre, y poda cada entorno a ese mismo conjunto. Cuál es el entorno activo es una preferencia local tuya y nunca va en el fichero.

Como ese fichero acaba compartiéndose, la exportación pasa antes por un diálogo. Ahí se enumera lo que ha encontrado con pinta de credencial, y se marca por ti Sustituir credenciales por __REDACTED__ cuando hay algo que ocultar. Sanear busca nombres que sugieran una credencial — cualquiera que contenga auth, token, secret, password, passwd, apikey, api_key, api-key, credential, signature, cookie o session — y sustituye el valor correspondiente por __REDACTED__. Revisa:

• Los nombres de header, tanto los de un mock como los de las operaciones de headers de petición/respuesta de una regla "Modificar headers".
• Los nombres de los parámetros de una regla "Parámetro de query".
• Los nombres de campo de un body JSON, a cualquier profundidad.
• La query string del propio patrón de URL de la regla y la de una URL de redirección — pero solo la query string. Un segmento de ruta puede ser cualquier cosa, y adivinar ahí destrozaría URL legítimas. Un patrón cuyo tipo de match sea Regex se salta entero, porque partir una regex por ? la corrompería.
• Los nombres de las variables — {{token}}, {{apiKey}} y compañía son el secreto más probable de todo el fichero. Las sobrescrituras de un entorno se juzgan por el nombre de la variable a la que apuntan, así que un token sobrescrito en "Prod" se redacta igual que la variable base.

Deliberadamente no toca:

• Bodies que no son JSON (texto plano, XML, form-encoded, etc.) — no hay forma fiable de distinguir un token de texto normal en un formato arbitrario, y adivinar mal corrompería el body en silencio. Solo se revisan los bodies que se pueden parsear como JSON, y el diálogo nombra los que no ha podido comprobar para que los revises tú.
• Un valor bajo un nombre de campo que no parece sensible — un token guardado bajo un campo literalmente llamado value o data no se detectaría, porque la comprobación se basa en el nombre, no en el contenido.
• Booleanos, o los literales "true"/"false", aunque estén bajo un nombre que parezca sensible. Un flag no es un secreto, y redactarlo solo produciría una regla rota.
• Dos nombres de header que parecen sensibles pero nunca lo son, tenga el valor que tenga: access-control-allow-credentials (un flag CORS fijo) y www-authenticate (el desafío que hace creíble un 401 mockeado).
• Los campos de una regla "Modificar el body de la respuesta real" — el texto que buscas y por el que lo reemplazas, y el valor nuevo del campo JSON. Se exportan tal como los escribiste, así que no dejes ahí un token antes de compartir el fichero.
• El nombre, la descripción y las etiquetas de la propia regla — eso lo escribes tú, así que no se revisa.

Trata "sanitizar al exportar" como una red de seguridad contra la fuga accidental más común, no como una garantía de que el fichero exportado no contiene ningún secreto — revisa lo que vas a compartir antes de enviarlo.

A la vuelta, Importar te deja elegir qué traer y avisa cuando una regla ya existe (mismo tipo, método y patrón), ofreciéndote importarla como copia, omitirla o sobrescribir la existente — con la misma elección, por separado, para las variables cuyo valor difiera del tuyo. Es el mismo camino que recorren una spec, una colección de Postman y un perfil de ModHeader, que por eso no tienen un mecanismo de importación aparte.