{"id":32089,"date":"2025-12-29T19:19:13","date_gmt":"2025-12-29T19:19:13","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/?p=32089"},"modified":"2026-07-02T12:40:51","modified_gmt":"2026-07-02T12:40:51","slug":"jsonpath-web-api-monitoring","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/jsonpath-web-api-monitoring\/","title":{"rendered":"JSONPath &#038; JSON Validation for Web API Monitoring Assertions"},"content":{"rendered":"<p><img fetchpriority=\"high\" decoding=\"async\" class=\"alignright wp-image-32090\" src=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/12\/jsonpath-web-api-monitoring.webp\" alt=\"JSONPath &amp; JSON Validation for Web API Monitoring Assertions\" width=\"480\" height=\"320\" srcset=\"https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/12\/jsonpath-web-api-monitoring.webp 1280w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/12\/jsonpath-web-api-monitoring-300x200.webp 300w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/12\/jsonpath-web-api-monitoring-1024x682.webp 1024w, https:\/\/www.dotcom-monitor.com\/blog\/wp-content\/uploads\/sites\/3\/2025\/12\/jsonpath-web-api-monitoring-768x512.webp 768w\" sizes=\"(max-width: 480px) 100vw, 480px\" \/>Most <b><a href=\"https:\/\/www.dotcom-monitor.com\/products\/api-monitoring\/\">API monitoring<\/a><\/b> setups still rely on a narrow definition of success: Did the endpoint respond, and did it return a 200 status code? While availability is essential, modern <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/api-uptime-monitoring\/\">API uptime tracking<\/a> must go beyond basic status checks for API-driven systems.<\/p>\n<p>In real production environments, APIs frequently return <b>successful HTTP responses with incorrect or incomplete payloads<\/b>. Authentication endpoints may issue tokens missing required fields. Business-critical APIs may return empty objects instead of valid data. Third-party APIs may change response structures without breaking status codes. From the outside, everything appears \u201cup\u201d, but integrations are already failing.<\/p>\n<p>This is why <b>API response validation<\/b> is a core requirement of continuous Web API monitoring. Monitoring must verify not just that an API responds, but that it responds <b>correctly and consistently<\/b>. Assertions allow teams to validate field existence, expected values, and response structure, catching silent failures before they cascade downstream.<\/p>\n<p>Unlike API tests run during CI\/CD, <a href=\"https:\/\/www.dotcom-monitor.com\/features\/assertions-monitoring\/\">monitoring assertions<\/a> operate continuously against live endpoints. They are designed to detect <b>regressions, contract drift, and partial failures<\/b> over time, not just during deployments. When implemented correctly, response validation becomes a critical safeguard for API reliability, SLAs, and customer-facing integrations.<\/p>\n<p>To put these ideas into context, it helps to understand <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/what-is-web-api-monitoring\/\"><b>how Web API monitoring works<\/b><\/a>, and how validation fits into a broader monitoring strategy that goes beyond uptime alone.<\/p>\n<h2 id='jsonpath-explained-what-it-does-and-what-it-doesn-t'  id=\"boomdevs_1\">JSONPath Explained: What It Does (and What It Doesn\u2019t)<\/h2>\n<p>JSONPath is a query language used to extract specific values from JSON responses. For APIs, it provides a precise way to locate fields, traverse nested objects, filter arrays, and apply conditional logic to response payloads.<\/p>\n<p>In <strong>Web API monitoring,<\/strong> JSONPath is most valuable when you need to confirm that <strong>critical response data exists and behaves as expected,<\/strong> while also helping teams <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/api-health-monitoring\/\">track API status<\/a> beyond simple availability checks. Common monitoring assertions include:<\/p>\n<p>In <b>Web API monitoring<\/b>, JSONPath is most valuable when you need to confirm that <b>critical response data exists and behaves as expected<\/b>. Common monitoring assertions include:<\/p>\n<ul>\n<li aria-level=\"1\">Verifying that required fields are present<\/li>\n<li aria-level=\"1\">Checking that values meet expected conditions<\/li>\n<li aria-level=\"1\">Confirming that arrays contain valid objects<\/li>\n<\/ul>\n<p>These checks go beyond simple status-code monitoring and help detect <b>silent failures<\/b>, cases where an API responds successfully but returns unusable data.<\/p>\n<p>That said, JSONPath is <b>not a full validation mechanism<\/b>.<\/p>\n<p>It works at the <b>path and value level<\/b>, not at the structural or contractual level. JSONPath can confirm that a field exists or matches a condition, but it cannot:<\/p>\n<ul>\n<li aria-level=\"1\">Enforce an entire response schema<\/li>\n<li aria-level=\"1\">Distinguish required vs. optional fields at scale<\/li>\n<li aria-level=\"1\">Protect against subtle structural changes across versions<\/li>\n<\/ul>\n<p>This limitation matters in production monitoring. Overusing JSONPath for deep structural checks often leads to <b>brittle assertions<\/b> that break during non-breaking API changes\u2014or miss meaningful regressions altogether.<\/p>\n<p>Effective monitoring uses JSONPath intentionally: to validate <b>what must be true for the API to function<\/b>, while relying on complementary validation methods when broader structural guarantees are required.<\/p>\n<h2 id='json-validation-vs-jsonpath-choosing-the-right-assertion-type'  id=\"boomdevs_2\">JSON Validation vs JSONPath: Choosing the Right Assertion Type<\/h2>\n<p>One of the most common mistakes teams make in API monitoring is treating <b>JSONPath and JSON validation as interchangeable<\/b>. While they\u2019re often used together, they solve <b>different problems<\/b> and should be applied intentionally.<\/p>\n<p><b>JSONPath assertions<\/b> focus on <i>values<\/i>. They answer questions like:<\/p>\n<ul>\n<li aria-level=\"1\">Does this field exist?<\/li>\n<li aria-level=\"1\">Does this value match an expected condition?<\/li>\n<li aria-level=\"1\">Does this array contain at least one valid object?<\/li>\n<\/ul>\n<p>These checks are lightweight and effective for monitoring business-critical fields that must be present for an API to function.<\/p>\n<p><b>JSON validation<\/b>, on the other hand, focuses on <i>structure<\/i>. It verifies that the response conforms to an expected shape (object hierarchy, required fields, and data types), helping detect breaking changes that value-level checks alone might miss.<\/p>\n<h3 id='when-jsonpath-alone-is-enough'  id=\"boomdevs_3\">When JSONPath Alone Is Enough<\/h3>\n<p>JSONPath is usually sufficient when:<\/p>\n<ul>\n<li aria-level=\"1\">The API contract is stable and well-controlled<\/li>\n<li aria-level=\"1\">You\u2019re validating a small set of critical fields<\/li>\n<li aria-level=\"1\">Minor structural changes are acceptable<\/li>\n<li aria-level=\"1\">The goal is early detection of functional failures<\/li>\n<\/ul>\n<p>This makes JSONPath ideal for monitoring authentication responses, key identifiers, or required business attributes.<\/p>\n<h3 id='when-json-validation-is-required'  id=\"boomdevs_4\">When JSON Validation Is Required<\/h3>\n<p>Structural validation becomes important when:<\/p>\n<ul>\n<li aria-level=\"1\">APIs are versioned or frequently updated<\/li>\n<li aria-level=\"1\">You rely on third-party or external APIs<\/li>\n<li aria-level=\"1\">Compliance or data integrity is critical<\/li>\n<li aria-level=\"1\">Structural drift could silently break integrations<\/li>\n<\/ul>\n<p>In these cases, JSON validation complements JSONPath by ensuring the <b>overall response remains compatible<\/b>, not just individual fields.<\/p>\n<p>The most resilient monitoring strategies combine both approaches: JSONPath to validate <b>what must be true right now<\/b>, and JSON validation to protect against <b>contract-level breakage<\/b> over time. For a deeper comparison of these approaches and where each fits best, this breakdown of <b>JSON validators vs Web API monitoring assertions<\/b> and this comparison of <b>JSONPath vs XPath vs jq for API response validation<\/b> provide additional context.<\/p>\n<h2 id='designing-monitoring-safe-jsonpath-assertions-not-test-only-assertions'  id=\"boomdevs_5\">Designing Monitoring-Safe JSONPath Assertions (Not Test-Only Assertions)<\/h2>\n<p>JSONPath assertions written for API tests often fail when reused for continuous monitoring. The reason is simple: <b>testing and monitoring have different goals<\/b>.<\/p>\n<p>API tests aim to catch regressions during controlled deployments. Monitoring assertions must survive <b>real-world variability<\/b> (partial outages, data edge cases, and non-breaking changes) without creating alert noise. Designing monitoring-safe JSONPath assertions requires a different mindset.<\/p>\n<h3 id='common-assertion-mistakes-in-production-monitoring'  id=\"boomdevs_6\">Common Assertion Mistakes in Production Monitoring<\/h3>\n<p>Many alerting issues stem from assertions that are too rigid. Common examples include:<\/p>\n<ul>\n<li aria-level=\"1\"><b>Hard-coded array indexes<\/b><b><br \/>\n<\/b>Assertions like $.items[0].id break when ordering changes, even if the data is valid.<\/li>\n<li aria-level=\"1\"><b>Exact value matching for dynamic fields<\/b><b><br \/>\n<\/b>IDs, timestamps, tokens, and pagination values change by design.<\/li>\n<li aria-level=\"1\"><b>Overuse of recursive descent (<\/b><b>..<\/b><b>)<\/b><b><br \/>\n<\/b>Recursive queries can match unintended fields and cause false positives.<\/li>\n<li aria-level=\"1\"><b>Treating optional fields as required<\/b><b><br \/>\n<\/b>APIs often omit optional data under valid conditions.<\/li>\n<\/ul>\n<p>These patterns may work in tests, but they\u2019re brittle in production monitoring.<\/p>\n<h3 id='best-practices-for-resilient-jsonpath-assertions'  id=\"boomdevs_7\">Best Practices for Resilient JSONPath Assertions<\/h3>\n<p>Monitoring-safe assertions focus on <b>functional correctness<\/b>, not cosmetic consistency:<\/p>\n<ul>\n<li aria-level=\"1\">Validate field existence before value matching<\/li>\n<li aria-level=\"1\">Use filters and conditions instead of fixed indexes<\/li>\n<li aria-level=\"1\">Assert on minimum expectations (e.g., \u201cat least one valid object\u201d)<\/li>\n<li aria-level=\"1\">Differentiate between required and optional fields<\/li>\n<li aria-level=\"1\">Alert on absence or invalid states, not benign variations<\/li>\n<\/ul>\n<p>This approach reduces false alerts while still catching real failures early.<\/p>\n<p>If you\u2019re unsure where the line should be drawn, it helps to clearly separate concerns between <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/api-testing-vs-web-api-monitoring\/\"><b>API testing and Web API monitoring<\/b><\/a>. Testing validates changes before release; monitoring validates behavior after release, continuously and externally.<\/p>\n<h2 id='assertion-failure-modes-you-must-account-for-in-real-apis'  id=\"boomdevs_8\">Assertion Failure Modes You Must Account for in Real APIs<\/h2>\n<p>Most API tutorials assume responses are either \u201ccorrect\u201d or \u201cbroken.\u201d In production, failures are rarely that clean. APIs often degrade <b>partially<\/b>, returning responses that look valid at first glance but break downstream behavior.<\/p>\n<p>Monitoring assertions need to account for these realities.<\/p>\n<h3 id='partial-and-incomplete-payloads'  id=\"boomdevs_9\">Partial and Incomplete Payloads<\/h3>\n<p>APIs may return only part of the expected data due to upstream timeouts, cache issues, or dependency failures. Required fields might be missing while the response still returns a 200 status code. JSONPath assertions that validate <b>field existence<\/b> are often the first line of defense against these silent failures.<\/p>\n<h3 id='null-values-vs-missing-keys'  id=\"boomdevs_10\">Null Values vs. Missing Keys<\/h3>\n<p>There\u2019s an important difference between a field that exists with a null value and a field that\u2019s missing entirely. Many integrations handle these cases differently. Monitoring assertions should distinguish between:<\/p>\n<ul>\n<li aria-level=\"1\">Fields that must exist and be non-null<\/li>\n<li aria-level=\"1\">Fields that may be null under valid conditions<\/li>\n<\/ul>\n<p>Treating these cases the same can either mask real issues or create unnecessary alerts.<\/p>\n<h3 id='pagination-and-dynamic-arrays'  id=\"boomdevs_11\">Pagination and Dynamic Arrays<\/h3>\n<p>APIs that paginate results or return variable-length arrays introduce additional edge cases. Assertions that assume fixed positions or minimum sizes can fail during normal operation. Instead, monitoring should verify <b>conditions<\/b>, such as the presence of at least one valid object or a non-zero count.<\/p>\n<h3 id='authentication-and-authorization-edge-cases'  id=\"boomdevs_12\">Authentication and Authorization Edge Cases<\/h3>\n<p>Authentication-related failures are especially common in real-world monitoring. <b><a href=\"https:\/\/www.dotcom-monitor.com\/blog\/monitoring-jwt-tokens-oauth-token-endpoints\/\">Expired tokens<\/a><\/b>, missing scopes, or misconfigured credentials may still produce structured error responses rather than outright failures. <b><a href=\"https:\/\/www.dotcom-monitor.com\/blog\/oauth-web-api-monitoring\/\">Monitoring OAuth-secured APIs<\/a><\/b> requires validating not just HTTP status codes, but also error fields and token-related attributes returned in the response.<\/p>\n<h3 id='third-party-api-contract-drift'  id=\"boomdevs_13\">Third-Party API Contract Drift<\/h3>\n<p>External APIs change more often than internal ones, and not always with advance notice. Field names, nesting, or optional attributes may shift without breaking compatibility from the provider\u2019s perspective. Monitoring assertions should be designed to detect <b>meaningful breakage<\/b> while tolerating benign changes, especially when dealing with third-party integrations.<\/p>\n<p>For teams monitoring authentication flows or external dependencies, additional guidance on <a href=\"https:\/\/www.dotcom-monitor.com\/blog\/monitoring-oauth-2-client-credentials-flow\/\"><b>monitoring OAuth 2.0 client credentials flow<\/b><\/a> and <b>third-party Web API monitoring<\/b> can help refine assertion strategies for these scenarios.<\/p>\n<h2 id='applying-jsonpath-json-validation-in-synthetic-api-monitoring'  id=\"boomdevs_14\">Applying JSONPath &amp; JSON Validation in Synthetic API Monitoring<\/h2>\n<p><b><a href=\"https:\/\/www.dotcom-monitor.com\/blog\/deep-dive-into-synthetic-api-monitoring\/\">Synthetic API monitoring<\/a><\/b> allows teams to simulate real user and system interactions with APIs\u2014continuously, from outside the network. This makes it an ideal place to apply <b>JSONPath and JSON validation assertions<\/b>, because every check runs in conditions that closely resemble real-world usage.<\/p>\n<p>In synthetic monitoring, assertions aren\u2019t isolated checks. They\u2019re part of a <b>multi-step workflow<\/b> that validates correctness across an entire transaction.<\/p>\n<h3 id='validating-multi-step-api-flows'  id=\"boomdevs_15\">Validating Multi-Step API Flows<\/h3>\n<p>Many APIs depend on sequential calls. A typical flow might include:<\/p>\n<ul>\n<li aria-level=\"1\">Authenticating and retrieving a token<\/li>\n<li aria-level=\"1\">Calling one or more protected endpoints<\/li>\n<li aria-level=\"1\">Validating business-critical data in the final response<\/li>\n<\/ul>\n<p>JSONPath assertions are used to extract values from one step (such as tokens or IDs) and confirm expected fields and conditions in subsequent responses. JSON validation adds another layer by ensuring the response structure remains compatible as the API evolves.<\/p>\n<h3 id='chained-assertions-and-failure-context'  id=\"boomdevs_16\">Chained Assertions and Failure Context<\/h3>\n<p>In synthetic monitoring, assertion failures don\u2019t exist in isolation. A failed JSONPath check can indicate:<\/p>\n<ul>\n<li aria-level=\"1\">Authentication problems<\/li>\n<li aria-level=\"1\">Downstream dependency failures<\/li>\n<li aria-level=\"1\">Incorrect data being returned under load<\/li>\n<\/ul>\n<p>By validating both values and structure, teams gain clearer context about <b>where<\/b> and <b>why<\/b> a failure occurs, making troubleshooting faster and more accurate.<\/p>\n<h3 id='from-validation-to-alerting'  id=\"boomdevs_17\">From Validation to Alerting<\/h3>\n<p>Unlike test environments, synthetic monitoring ties assertion failures directly to alerting logic. When a JSONPath or validation check fails, the monitoring system can trigger alerts immediately, before users are affected. This is especially important for APIs that underpin customer-facing features or critical integrations.<\/p>\n<p>For organizations looking to implement this approach at scale, <a href=\"https:\/\/www.dotcom-monitor.com\/features\/synthetic-monitoring\/\"><b>synthetic monitoring<\/b><\/a> combined with dedicated <a href=\"https:\/\/www.dotcom-monitor.com\/products\/api-monitoring\/\"><b>Web API monitoring tool<\/b><\/a> provides the foundation for validating correctness, availability, and performance in one continuous workflow.<\/p>\n<h2 id='from-assertions-to-action-alerts-dashboards-and-reporting'  id=\"boomdevs_18\">From Assertions to Action: Alerts, Dashboards, and Reporting<\/h2>\n<p>Assertions only become valuable when they lead to <b>actionable insight<\/b>. In Web API monitoring, JSONPath and JSON validation checks are not just pass\/fail conditions, they are signals that feed alerting, visibility, and long-term analysis.<\/p>\n<p>When an assertion fails, it indicates more than a broken endpoint. It can signal incorrect data being returned, authentication issues, or subtle regressions that haven\u2019t yet impacted availability. By tying assertion failures directly to alerts, teams can respond <b>before downstream systems or users are affected<\/b>.<\/p>\n<h3 id='turning-assertion-failures-into-alerts'  id=\"boomdevs_19\">Turning Assertion Failures into Alerts<\/h3>\n<p>Effective alerting starts with intent. Not every validation failure should trigger the same response. Monitoring systems should allow teams to distinguish between:<\/p>\n<ul>\n<li aria-level=\"1\">Critical assertion failures that require immediate attention<\/li>\n<li aria-level=\"1\">Degraded responses that warrant investigation but not escalation<\/li>\n<\/ul>\n<p>This approach helps prevent alert fatigue while ensuring meaningful issues are surfaced quickly.<\/p>\n<h3 id='visualizing-trends-and-patterns'  id=\"boomdevs_20\">Visualizing Trends and Patterns<\/h3>\n<p>Beyond real-time alerts, assertion data becomes far more valuable when viewed over time. Dashboards and reports allow teams to identify recurring failures, track the stability of key response fields, and correlate validation issues with broader availability or performance events. This visibility supports SLA tracking, root cause analysis, and informed decision-making, without requiring deep manual log inspection.<\/p>\n<p>For organizations monitoring business-critical APIs, integrating assertions with <a href=\"https:\/\/www.dotcom-monitor.com\/features\/reports\/\"><b>dashboards and reports<\/b><\/a> helps turn raw validation results into operational intelligence. When combined with <b>Web API latency and SLA monitoring<\/b>, teams gain a clearer picture of how correctness, performance, and availability interact across their API ecosystem.<\/p>\n<h2 id='how-to-set-up-jsonpath-assertions-in-dotcom-monitor-practical-next-steps'  id=\"boomdevs_21\">How to Set Up JSONPath Assertions in Dotcom-Monitor (Practical Next Steps)<\/h2>\n<p>Once you\u2019ve defined which fields and structures matter for your APIs, the next step is translating those requirements into monitoring assertions. In Dotcom-Monitor, JSONPath assertions are configured as part of <b>REST Web API monitoring tasks<\/b>, allowing you to validate responses continuously from external monitoring locations.<\/p>\n<p>The process starts by defining the API endpoint and request parameters, including headers, authentication details, and request method. From there, you can specify validation rules that apply to the response body. JSONPath expressions are used to locate fields and apply conditions, such as confirming that required values exist, arrays contain valid objects, or error indicators are absent.<\/p>\n<p>For APIs that involve multiple steps, such as authentication followed by protected resource access, assertions can be applied at each stage of the workflow. This ensures that failures are detected at the correct step, whether the issue lies in token retrieval, authorization, or business data returned by the API.<\/p>\n<p>Dotcom-Monitor\u2019s configuration approach allows teams to update or refine assertions as APIs evolve, without needing to rewrite entire monitoring setups. This is especially useful when working with versioned APIs or third-party services where response structures may change over time.<\/p>\n<p><em>Learn more about <a href=\"https:\/\/www.dotcom-monitor.com\/products\/api-monitoring\/rest-api-monitoring\/\">REST endpoint monitoring<\/a> and how it can improve your overall monitoring strategy.<\/em><\/p>\n<div class=\"dcm_inblog_cta\">\n<p style=\"font-size: 22px; text-align: left;\">To get started, these guides walk through the practical setup and configuration steps:<\/p>\n<ul style=\"font-size: 22px; text-align: left;\">\n<li>How to <a href=\"https:\/\/www.dotcom-monitor.com\/wiki\/knowledge-base\/configuring-rest-web-api-task\/\">configure a REST Web API monitoring task<\/a><\/li>\n<li>How to <a href=\"https:\/\/www.dotcom-monitor.com\/wiki\/knowledge-base\/add-edit-rest-web-api-task\/\">add or edit REST Web API tasks<\/a><\/li>\n<li>How to complete a full <a href=\"https:\/\/www.dotcom-monitor.com\/wiki\/knowledge-base\/web-api-monitoring-setup\/\">Web API monitoring setup<\/a><\/li>\n<\/ul>\n<\/div>\n<h2 id='validate-api-responses-before-they-break-your-integrations'  id=\"boomdevs_22\">Validate API Responses Before They Break Your Integrations<\/h2>\n<p>APIs rarely fail all at once. More often, they degrade quietly\u2014returning incomplete, incorrect, or unexpected data while still appearing available. JSONPath and JSON validation assertions give teams the visibility needed to catch these issues early, before they impact users, partners, or downstream systems.<\/p>\n<p>By combining value-level checks with structural validation in continuous Web API monitoring, teams can move beyond basic uptime checks and start monitoring what actually matters: <b>correctness, consistency, and reliability over time<\/b>. This approach helps reduce alert fatigue, surface meaningful failures faster, and maintain confidence in critical API integrations.<\/p>\n<p>If you\u2019re ready to apply these practices in a production monitoring environment, explore how <a href=\"https:\/\/www.dotcom-monitor.com\/products\/api-monitoring\/\">Dotcom-Monitor\u2019s Web API monitoring platform<\/a> supports assertion-based validation, synthetic monitoring, and real-time alerting, without the complexity of building and maintaining custom tooling.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Most API monitoring setups still rely on a narrow definition of success: Did the endpoint respond, and did it return a 200 status code? While availability is essential, it\u2019s no longer enough for modern, API-driven systems.<\/p>\n","protected":false},"author":39,"featured_media":32090,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-32089","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/posts\/32089","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/users\/39"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/comments?post=32089"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/posts\/32089\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/media\/32090"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/media?parent=32089"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/categories?post=32089"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/wp-json\/wp\/v2\/tags?post=32089"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}