{"id":31206,"date":"2025-11-21T22:53:28","date_gmt":"2025-11-21T22:53:28","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/synthetic-monitoring-servicenow\/"},"modified":"2026-05-22T05:27:53","modified_gmt":"2026-05-22T05:27:53","slug":"synthetic-monitoring-servicenow","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/es\/synthetic-monitoring-servicenow\/","title":{"rendered":"Monitorizaci\u00f3n sint\u00e9tica para ServiceNow: Tablas, Reglas y Endpoints"},"content":{"rendered":"<p><img fetchpriority=\"high\" decoding=\"async\" class=\"alignright wp-image-31194\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/11\/synthetic-monitoring-servicenow.webp\" alt=\"Synthetic Monitoring for ServiceNow\" width=\"480\" height=\"320\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/11\/synthetic-monitoring-servicenow.webp 1280w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/11\/synthetic-monitoring-servicenow-300x200.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/11\/synthetic-monitoring-servicenow-1024x682.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/11\/synthetic-monitoring-servicenow-768x512.webp 768w\" sizes=\"(max-width: 480px) 100vw, 480px\" \/>ServiceNow es una de esas plataformas que parece sencilla desde fuera pero que se convierte en un laberinto en el momento en que una organizaci\u00f3n empieza a personalizarla. Lo que comienza como un cat\u00e1logo de servicios o un portal de RR. HH. evoluciona r\u00e1pidamente en un enredo de tablas personalizadas, pol\u00edticas de interfaz, reglas de negocio, acciones de Flow Designer y endpoints REST scriptados. Nada de esto es malo. De hecho, es la raz\u00f3n por la que las empresas eligen ServiceNow: puedes construir pr\u00e1cticamente cualquier cosa.<\/p>\n<p>Pero con esa flexibilidad llega la fragilidad. En el momento en que introduces l\u00f3gica personalizada \u2014especialmente l\u00f3gica que depende de otra l\u00f3gica\u2014 creas modos de fallo que no aparecen en la monitorizaci\u00f3n integrada y que no son visibles en la mayor\u00eda de los paneles internos. Una instancia de ServiceNow puede parecer saludable sobre el papel mientras el portal es completamente inutilizable para usuarios reales.<\/p>\n<p>Ah\u00ed es donde encaja la monitorizaci\u00f3n sint\u00e9tica. No los \u201csint\u00e9ticos\u201d ligeros que ServiceNow ejecuta internamente para validar flujos de trabajo, sino la monitorizaci\u00f3n externa a nivel de navegador que simula la manera en que un usuario real interact\u00faa con tu portal. La diferencia entre ambos es la diferencia entre comprobar el latido de un servidor y comprobar si un humano puede realmente enviar un ticket.<\/p>\n<p>Los sint\u00e9ticos externos captan los fallos que se originan en tus tablas personalizadas, tus scripts cliente, tus APIs scriptadas \u2014y, en \u00faltima instancia, tus decisiones de dise\u00f1o. A medida que crece el n\u00famero de partes m\u00f3viles, la \u00fanica forma fiable de confirmar que tu portal ServiceNow funciona es usar algo que se comporte como una persona real accediendo desde Internet.<\/p>\n<p>Este es el alcance de este art\u00edculo: por qu\u00e9 las personalizaciones de ServiceNow son la ra\u00edz de la mayor\u00eda de las roturas, por qu\u00e9 las herramientas nativas no pueden verlo y c\u00f3mo la monitorizaci\u00f3n sint\u00e9tica cubre esa laguna.<\/p>\n<h2 id='por-qu\u00e9-las-personalizaciones-de-servicenow-rompen-la-experiencia-del-portal'  id=\"boomdevs_1\">Por qu\u00e9 las personalizaciones de ServiceNow rompen la experiencia del portal<\/h2>\n<p>La Now Platform ofrece a las organizaciones una enorme superficie para personalizar. Y debido a que la estructura subyacente es tan modular, es f\u00e1cil suponer que un peque\u00f1o cambio en un sitio no tendr\u00e1 consecuencias en otro.<\/p>\n<p>En realidad, casi todo en ServiceNow es relacional: las tablas personalizadas hacen referencia a otras tablas, las reglas se disparan contra clases heredadas, los scripts mutan estados de los que dependen otros scripts. Incluso elementos de UI que parecen simples en el navegador pueden estar impulsados por una pila de consultas GlideRecord, comprobaciones ACL y reglas de negocio del lado servidor.<\/p>\n<p>Cuando algo va mal, rara vez parece un evento tradicional de \u201cca\u00edda\u201d. En su lugar, los usuarios ven s\u00edntomas como:<\/p>\n<ul>\n<li>P\u00e1ginas que cargan lentamente hasta agotar el tiempo.<\/li>\n<li>Elementos del cat\u00e1logo que se quedan congelados tras pulsar Enviar.<\/li>\n<li>Widgets que giran sin parar porque una API personalizada devolvi\u00f3 JSON incompleto.<\/li>\n<li>Resultados de b\u00fasqueda que de repente no devuelven nada porque una regla ajust\u00f3 la herencia de ACL.<\/li>\n<li>Una p\u00e1gina de conocimiento que funciona internamente pero falla en cuanto alguien la accede mediante SSO.<\/li>\n<\/ul>\n<p>Para la infraestructura de ServiceNow, todo est\u00e1 \u201cactivo\u201d. Pero para tus empleados o clientes, el portal podr\u00eda estar fuera de servicio.<\/p>\n<p>Estos modos de fallo no emergen de la plataforma base; emergen de c\u00f3mo ha sido personalizada. Tablas, reglas, endpoints \u2014cada uno introduce un punto d\u00e9bil. La monitorizaci\u00f3n sint\u00e9tica funciona porque no le importa el estado interno de la instancia. Solo le importa si el portal se comporta correctamente.<\/p>\n<h2 id='los-puntos-ciegos-en-la-monitorizaci\u00f3n-nativa-de-servicenow'  id=\"boomdevs_2\">Los puntos ciegos en la monitorizaci\u00f3n nativa de ServiceNow<\/h2>\n<p>ServiceNow s\u00ed tiene monitorizaci\u00f3n \u201csint\u00e9tica\u201d integrada en la plataforma. Pero es monitorizaci\u00f3n sint\u00e9tica interna: comprobaciones que se ejecutan desde dentro de la instancia, validando la ejecuci\u00f3n de workflows, la l\u00f3gica de negocio y los SLA b\u00e1sicos.<\/p>\n<p>\u00bf\u00datil? S\u00ed. \u00bfSuficiente? Ni de lejos.<\/p>\n<p>Los sint\u00e9ticos internos viven en las mismas condiciones que el portal. No atraviesan VPNs, firewalls corporativos, geograf\u00edas distintas, proveedores de identidad de terceros, capas DNS ni CDNs. No cargan un navegador, no ejecutan JavaScript ni renderizan el portal en algo que se parezca al entorno de un usuario real. No siguen journeys de m\u00faltiples pasos a trav\u00e9s de cat\u00e1logos, aprobaciones, scripts e integraciones de back-end.<\/p>\n<p>Y lo m\u00e1s importante: no tocan lo que m\u00e1s se rompe: tu c\u00f3digo personalizado. Ocurrencias comunes son:<\/p>\n<ul>\n<li>Un script cliente personalizado que lanza un error no desencadena una falla en el sint\u00e9tico interno.<\/li>\n<li>Una acci\u00f3n de Flow Designer que se queda estancada porque una API de terceros es lenta no disparar\u00e1 alertas internas.<\/li>\n<li>El endpoint de una scoped app que devuelve una carga malformada no se registrar\u00e1 como no saludable a menos que lo pruebes espec\u00edficamente.<\/li>\n<li>Una regresi\u00f3n de rendimiento del lado del navegador provocada por una modificaci\u00f3n de un widget no aparecer\u00e1 en los logs del servidor.<\/li>\n<\/ul>\n<p>La monitorizaci\u00f3n nativa valida la plataforma. La monitorizaci\u00f3n sint\u00e9tica externa valida la experiencia.<\/p>\n<p>Si solo miras lo que ocurre dentro de ServiceNow, siempre estar\u00e1s medio ciego.<\/p>\n<h2 id='monitorizando-tablas-personalizadas-cuando-la-arquitectura-de-datos-rompe-la-ux'  id=\"boomdevs_3\">Monitorizando tablas personalizadas: cuando la arquitectura de datos rompe la UX<\/h2>\n<p>Todo en ServiceNow se asienta sobre tablas, y en el momento en que una organizaci\u00f3n introduce tablas personalizadas, el grafo de dependencias crece geom\u00e9tricamente. Una nueva subclase de incidente, un record producer con su propio esquema, una extensi\u00f3n CMDB personalizada \u2014cada uno se convierte en una nueva fuente de deriva potencial.<\/p>\n<p>Los mayores problemas aparecen en el portal mucho antes de que alguien los note en la instancia.<\/p>\n<ul>\n<li>Una actualizaci\u00f3n de ACL que parec\u00eda inocua bloquea de repente el rellenado de un campo de referencia, lo que se traduce en un elemento del cat\u00e1logo que parece \u201ccongelarse\u201d.<\/li>\n<li>Una tabla personalizada hereda de un padre que ha sido modificado con el tiempo, y ahora una regla que depende de un campo concreto no se dispara.<\/li>\n<li>Las consultas GlideRecord se ralentizan a medida que aumentan los registros, y el portal entra en timeout aunque la instancia muestre CPU normal.<\/li>\n<li>Una dependencia entre tablas se rompe en silencio, dejando workflows atascados en \u201crequested\u201d sin mensajes de error.<\/li>\n<\/ul>\n<p>Estos no son cortes en el sentido tradicional. Son fallos de flujo de trabajo. Y son invisibles a menos que pruebes los componentes reales del portal que dependen de esas tablas.<\/p>\n<p>La monitorizaci\u00f3n sint\u00e9tica detecta esto porque entrelaza todo el flujo dependiente de tablas: abrir cat\u00e1logo > rellenar campos > enviar > verificar el cambio de estado. Ves todo el camino, no solo las partes que ServiceNow cree que est\u00e1n bien.<\/p>\n<h2 id='monitorizando-reglas-de-negocio-y-scripts-cliente'  id=\"boomdevs_4\">Monitorizando reglas de negocio y scripts cliente<\/h2>\n<p>Las reglas son la parte m\u00e1s peligrosamente enga\u00f1osa de ServiceNow porque se encadenan de maneras sutiles. Una regla de negocio se dispara despu\u00e9s de un insert, lo que activa una acci\u00f3n de Flow Designer que actualiza un campo, que dispara un script include, que llama a una API personalizada \u2014y de repente el simple env\u00edo de un ticket se convierte en un sistema distribuido.<\/p>\n<p>Los scripts cliente crean otra modalidad de fallo: una condici\u00f3n err\u00f3nea, una variable ausente o una nueva pol\u00edtica de UI que entra en conflicto con una antigua. Estas fallas no aparecen en los logs como errores obvios. Aparecen en el navegador como retardos, botones congelados y comportamientos inconsistentes del formulario.<\/p>\n<p>Es en el portal donde la combinaci\u00f3n de reglas de negocio + scripts cliente se revela.<\/p>\n<p>La monitorizaci\u00f3n sint\u00e9tica detecta:<\/p>\n<ol>\n<li>Una regla de negocio que provoca una consulta Glide lenta que dispara los tiempos de env\u00edo.<\/li>\n<li>Una UI policy que se dispara incorrectamente cuando campos espec\u00edficos est\u00e1n vac\u00edos.<\/li>\n<li>Un script cliente que se rompe solo en Chrome, no en Firefox.<\/li>\n<li>Una regla que reencamina datos a la tabla equivocada por deriva de herencia.<\/li>\n<\/ol>\n<p>Los sint\u00e9ticos internos de ServiceNow reportar\u00e1n alegremente \u201ctodos los sistemas normales\u201d mientras los usuarios inundan el servicio de ayuda con capturas de pantalla de widgets girando.<\/p>\n<p>Las pruebas outside-in son la \u00fanica manera fiable de detectar si la pila de reglas se comporta como esperas.<\/p>\n<h2 id='monitorizando-endpoints-personalizados-e-integraciones'  id=\"boomdevs_5\">Monitorizando endpoints personalizados e integraciones<\/h2>\n<p>Los endpoints personalizados son donde un portal ServiceNow deja de ser una interfaz web simple y empieza a comportarse como una aplicaci\u00f3n real. Las organizaciones extienden la plataforma con APIs REST scriptadas, registros de integraci\u00f3n, acciones de Flow Designer que llaman a sistemas externos, endpoints de apps scoped y una mezcla de webhooks entrantes y salientes. Cada a\u00f1adido profundiza la cadena de dependencias, y cada dependencia introduce un punto de fallo que vive fuera del entorno central de ServiceNow.<\/p>\n<p>Aqu\u00ed es donde se origina gran parte de las roturas del portal. Una REST scriptada que funciona mal hace que el widget que depende de ella gire indefinidamente. Una integraci\u00f3n externa lenta hace que los env\u00edos del cat\u00e1logo queden colgados el tiempo suficiente para que los usuarios asuman que han fallado. Sistemas middleware como MuleSoft o Workato pueden imponer l\u00edmites de tasa o throttling intermitente, y cuando eso sucede, ServiceNow a menudo responde con estados de error vagos que no ofrecen pistas significativas al usuario. Incluso algo tan sutil como un endpoint que devuelve JSON malformado o parcial es suficiente para romper componentes de UI de maneras que no aparecen como errores tradicionales.<\/p>\n<p>Ninguno de estos problemas aparece en la monitorizaci\u00f3n nativa de ServiceNow. La plataforma solo ve su propia infraestructura, no las llamadas externas de las que dependen tus personalizaciones. Pero una prueba sint\u00e9tica trata esas dependencias como ciudadanos de primera clase del flujo de trabajo. Carga el widget, desencadena la llamada API, procesa la respuesta, actualiza las tablas relevantes y verifica el estado final tal como lo har\u00eda un usuario real. Esa cadena completa \u2014la combinaci\u00f3n de comportamiento del navegador, condiciones de red, rendimiento de endpoints y l\u00f3gica de la plataforma\u2014 es lo que determina si el portal funciona realmente.<\/p>\n<p>Si no pruebas continuamente todo el flujo, conf\u00edas en la esperanza en lugar de en la validaci\u00f3n. Y en un entorno ServiceNow personalizado, la esperanza no es una estrategia.<\/p>\n<h2 id='monitorizaci\u00f3n-sint\u00e9tica-outside-in-para-portales-servicenow'  id=\"boomdevs_6\">Monitorizaci\u00f3n sint\u00e9tica outside-in para portales ServiceNow<\/h2>\n<p>La monitorizaci\u00f3n sint\u00e9tica a nivel de navegador es fundamentalmente distinta de las comprobaciones internas de workflows. Carga tu portal exactamente como lo hace un usuario: desde una m\u00e1quina real, ejecutando un navegador real, por Internet p\u00fablico.<\/p>\n<p>Esto recrea todo el recorrido:<\/p>\n<ol>\n<li>Resoluci\u00f3n DNS<\/li>\n<li>Enrutamiento por CDN<\/li>\n<li>Pasarelas corporativas o en la nube<\/li>\n<li>SSO o proveedores de identidad externos<\/li>\n<li>Ejecuci\u00f3n de JavaScript<\/li>\n<li>Renderizado de widgets<\/li>\n<li>Llamadas API<\/li>\n<li>Actualizaciones de tablas<\/li>\n<li>Respuestas del portal<\/li>\n<\/ol>\n<p>Es la diferencia entre comprobar si el motor funciona y comprobar si el coche realmente se mueve.<\/p>\n<p>Para portales ServiceNow \u2014especialmente aquellos con amplias personalizaciones\u2014 esta es la \u00fanica manera de capturar la realidad.<\/p>\n<ul>\n<li>Si una p\u00e1gina tarda 7 segundos en cargar, lo ves.<\/li>\n<li>Si un widget lanza un error en la consola, lo ves.<\/li>\n<li>Si un endpoint personalizado devuelve JSON malformado, la prueba falla exactamente como fallar\u00eda un usuario.<\/li>\n<li>Si una actualizaci\u00f3n de release cambia el comportamiento de un script, los tiempos de los pasos se disparan.<\/li>\n<\/ul>\n<p>Los sint\u00e9ticos outside-in no se preocupan de si la instancia cree estar sana. Se preocupan de si un humano puede completar la tarea.<\/p>\n<h2 id='modelando-recorridos-reales-del-portal-servicenow'  id=\"boomdevs_7\">Modelando recorridos reales del portal ServiceNow<\/h2>\n<p>Los portales ServiceNow no son aplicaciones lineales; son flujos ramificados. Una buena prueba sint\u00e9tica refleja eso. El objetivo no es hacer clic por las p\u00e1ginas al azar, sino validar la l\u00f3gica de negocio incrustada en las tablas, reglas y endpoints que tu organizaci\u00f3n ha creado.<\/p>\n<p>Una prueba adecuada refleja un flujo real:<\/p>\n<ol>\n<li>Autenticarse (a menudo mediante SSO).<\/li>\n<li>Abrir el portal personalizado o el cat\u00e1logo de servicios.<\/li>\n<li>Buscar un elemento del cat\u00e1logo que dependa de tablas personalizadas.<\/li>\n<li>Rellenar campos que desencadenen scripts cliente o pol\u00edticas UI.<\/li>\n<li>Enviar, provocando reglas de negocio y llamadas a endpoints.<\/li>\n<li>Validar el registro resultante en la tabla correcta.<\/li>\n<li>Confirmar que los cambios de estado posteriores se propagan.<\/li>\n<\/ol>\n<p>Esto recrea cada paso donde normalmente ocurren fallos.<\/p>\n<p>Las buenas pruebas sint\u00e9ticas incluyen:<\/p>\n<ul>\n<li>Esperas din\u00e1micas para la carga as\u00edncrona de widgets.<\/li>\n<li>Aserciones vinculadas a valores reales de datos, no a texto est\u00e1tico.<\/li>\n<li>Verificaci\u00f3n de que el ticket llega a la tabla correcta con el estado correcto.<\/li>\n<li>Comprobaciones de que los endpoints personalizados devuelven los objetos esperados.<\/li>\n<li>An\u00e1lisis de tiempos que revela reglas, scripts o integraciones lentas.<\/li>\n<\/ul>\n<p>Esto no es un chequeo ligero de salud. Es una verificaci\u00f3n comportamental full-stack de la aplicaci\u00f3n personalizada que tu equipo ha construido sobre ServiceNow.<\/p>\n<h2 id='detectando-regresiones-en-upgrades-y-releases-de-servicenow'  id=\"boomdevs_8\">Detectando regresiones en upgrades y releases de ServiceNow<\/h2>\n<p>Las actualizaciones semestrales de ServiceNow son una fuente predecible de fallos impredecibles. Incluso con pruebas cuidadosas en preproducci\u00f3n, se escapan regresiones sutiles porque el comportamiento de la plataforma puede cambiar de formas que solo se hacen visibles en un entorno totalmente personalizado. Un script cliente que funcionaba perfectamente en una release puede romperse tras un cambio en el framework de UI. Un widget personalizado puede depender de dependencias que han sido refactorizadas silenciosamente. Una regla de negocio puede empezar a dispararse dos veces por un cambio en el orden de ejecuci\u00f3n. Las acciones del Flow Designer pueden devolver estructuras de salida ligeramente diferentes, y las consultas GlideRecord pueden comportarse distinto por cambios en la indexaci\u00f3n u optimizaciones de consulta.<\/p>\n<p>No son fallos dram\u00e1ticos; son fallos de segundo orden que emergen en el portal, normalmente como lentitud, comportamiento inesperado de formularios o componentes que se niegan a cargar. Y como tantas personalizaciones dependen de tablas heredadas o abstracciones de la plataforma, incluso peque\u00f1os cambios reverberan hasta que algo se rompe.<\/p>\n<p>La monitorizaci\u00f3n sint\u00e9tica es la \u00fanica forma fiable de sacar a la luz estos problemas antes de que los usuarios los experimenten. Mientras las pruebas manuales de upgrade se centran en caminos conocidos, los sint\u00e9ticos validan los workflows vivos: elementos del cat\u00e1logo, creaci\u00f3n de tickets, aprobaciones, comportamientos de b\u00fasqueda y componentes dependientes de integraciones. Horas despu\u00e9s de una actualizaci\u00f3n, los usuarios terminar\u00e1n reportando qu\u00e9 se ha roto. La monitorizaci\u00f3n sint\u00e9tica te da esa visibilidad de inmediato, proporcionando una red de seguridad contra regresiones que permanece mucho tiempo despu\u00e9s de la ventana de upgrade.<\/p>\n<h2 id='d\u00f3nde-encaja-dotcom-monitor'  id=\"boomdevs_9\">D\u00f3nde encaja Dotcom-Monitor<\/h2>\n<p>Dotcom-Monitor no reemplaza las herramientas internas de ServiceNow. Las complementa llenando la laguna de visibilidad entre la plataforma y la experiencia del usuario.<\/p>\n<p>Con monitorizaci\u00f3n en navegador real, obtienes tiempos por paso que reflejan el rendimiento en el cliente, no solo el estado del servidor. Con monitorizaci\u00f3n de APIs, puedes validar endpoints personalizados e integraciones de forma independiente. Con ubicaciones globales, ves c\u00f3mo diferentes redes y regiones interact\u00faan con tu portal. Y con scripting multi-pasos, puedes modelar exactamente los workflows que dependen de tus tablas, reglas y endpoints personalizados.<\/p>\n<p>En otras palabras: la monitorizaci\u00f3n interna mantiene la plataforma honesta, y la monitorizaci\u00f3n externa mantiene la <em>experiencia<\/em> honesta.<\/p>\n<h2 id='conclusi\u00f3n'  id=\"boomdevs_10\">Conclusi\u00f3n<\/h2>\n<p>ServiceNow se vuelve potente gracias a la personalizaci\u00f3n. Se vuelve fr\u00e1gil por la misma raz\u00f3n. Cada tabla personalizada, regla y endpoint introduce nuevas maneras en que el portal puede fallar \u2014a menudo de forma silenciosa y sin indicios en las herramientas nativas de ServiceNow.<\/p>\n<p>La monitorizaci\u00f3n sint\u00e9tica cierra la brecha de visibilidad recreando el recorrido completo desde la perspectiva del usuario. Valida los workflows que dependen de tus estructuras de datos personalizadas. Detecta problemas de comportamiento introducidos por scripts y reglas. Expone las fallas ocultas tras llamadas API e integraciones. Y hace todo esto de forma continua, independientemente de lo saludable que la instancia crea estar.<\/p>\n<p>Para organizaciones que dependen de ServiceNow como puerta de entrada \u2014ya sea para ITSM, RR. HH., portales de clientes o aplicaciones a medida\u2014 la validaci\u00f3n outside-in no es opcional. Es la \u00fanica forma fiable de saber si el portal funciona.<\/p>\n<p>Tablas. Reglas. Endpoints. Son el n\u00facleo de tus personalizaciones ServiceNow \u2014y el n\u00facleo de tu estrategia de monitorizaci\u00f3n. Los sint\u00e9ticos externos garantizan que se comporten como pretend\u00edas, no solo como la plataforma lo reporta.<\/p>\n<div class=\"dcm_inblog_cta\">Comienza con la monitorizaci\u00f3n sint\u00e9tica externa de Dotcom-Monitor para ServiceNow registr\u00e1ndote en una <a href=\"https:\/\/userauth.dotcom-monitor.com\/Account\/FreeTrialSignUp?SolutionType=Monitoring\">prueba gratuita hoy mismo<\/a>!<\/div>\n","protected":false},"excerpt":{"rendered":"<p>Aprende c\u00f3mo monitorizar portales ServiceNow desde el exterior y detectar fallos en tablas personalizadas, reglas de negocio y endpoints de API que afectan la experiencia del usuario.<\/p>\n","protected":false},"author":39,"featured_media":31200,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[875],"tags":[],"class_list":["post-31206","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sin-categorizar"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts\/31206","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/users\/39"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/comments?post=31206"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/posts\/31206\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/media\/31200"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/media?parent=31206"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/categories?post=31206"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/es\/wp-json\/wp\/v2\/tags?post=31206"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}