{"id":5520,"date":"2026-01-07T10:00:40","date_gmt":"2026-01-07T18:00:40","guid":{"rendered":"https:\/\/www.sslshopper.com\/website-monitoring\/?p=5520"},"modified":"2026-01-07T10:00:42","modified_gmt":"2026-01-07T18:00:42","slug":"api-uptime-monitoring","status":"publish","type":"post","link":"https:\/\/www.sslshopper.com\/website-monitoring\/api-uptime-monitoring\/","title":{"rendered":"API Uptime Monitoring: Endpoints, Auth, Rate Limits, Payload Checks"},"content":{"rendered":"\n<p><strong><mark style=\"background-color:var(--base)\" class=\"has-inline-color has-contrast-3-color\">[1,315 words, 7 minute read time]<\/mark><\/strong><\/p>\n\n\n\n<p>If you run a SaaS product, your API is the product\u2014at least for some percentage of customers. And APIs fail in a way that classic \u201cping the server\u201d monitoring simply won\u2019t catch:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>the endpoint responds <strong>200<\/strong>, but returns the wrong payload<\/li>\n\n\n\n<li>auth works, but only for certain token scopes<\/li>\n\n\n\n<li>latency spikes cause timeouts for customers even though your monitors show \u201cup\u201d<\/li>\n\n\n\n<li>downstream dependencies fail and your API returns \u201csuccess\u201d with empty data<\/li>\n<\/ul>\n\n\n\n<p><strong>APIs can be \u201cup\u201d but failing\u2014validate what matters.<\/strong><\/p>\n\n\n\n<p>This guide explains <strong>API uptime monitoring<\/strong> for technical teams: endpoint vs transaction monitoring, safe auth handling, payload validation patterns (no code required), rate limit awareness, and how to tie monitoring to error budgets and reliability metrics.<\/p>\n\n\n\n<p>For multi-step monitoring, dependency checks, and at-scale alert routing, see the <strong><a href=\"https:\/\/www.sslshopper.com\/website-monitoring\/advanced-monitoring\/\">advanced monitoring hub<\/a><\/strong>.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">What \u201cAPI uptime\u201d should mean (beyond 200 OK)<\/h2>\n\n\n\n<p>For APIs, \u201cup\u201d should usually mean at least three things:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Available:<\/strong> requests are accepted and answered<\/li>\n\n\n\n<li><strong>Correct:<\/strong> responses contain the expected data shape\/fields and semantics<\/li>\n\n\n\n<li><strong>Fast enough:<\/strong> responses are within an acceptable latency target<\/li>\n<\/ol>\n\n\n\n<p>A monitoring plan that checks only availability (e.g., \u201c200 OK\u201d) will miss the failures customers actually feel.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Endpoint monitoring vs transaction monitoring<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Endpoint monitoring (single request checks)<\/h3>\n\n\n\n<p><strong>What it is:<\/strong> monitoring one endpoint per check (e.g., <code>GET \/health<\/code>, <code>GET \/status<\/code>, <code>GET \/v1\/users\/me<\/code>).<\/p>\n\n\n\n<p><strong>Good for:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>basic availability and latency tracking<\/li>\n\n\n\n<li>quick detection of widespread outages<\/li>\n\n\n\n<li>validating specific endpoints that often break<\/li>\n<\/ul>\n\n\n\n<p><strong>Limitations:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>can miss failures that occur only when multiple steps happen (auth \u2192 fetch \u2192 write)<\/li>\n\n\n\n<li>may show \u201cup\u201d when the critical journey is broken<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Transaction monitoring (multi-step \/ synthetic API journeys)<\/h3>\n\n\n\n<p><strong>What it is:<\/strong> a sequence of API calls that represents real usage:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>authenticate \u2192 read resource \u2192 write\/update \u2192 confirm result<\/li>\n<\/ul>\n\n\n\n<p><strong>Good for:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>detecting broken flows (token exchange failing, permissions wrong, writes failing)<\/li>\n\n\n\n<li>catching regressions after deploys (schema changes, validation changes)<\/li>\n\n\n\n<li>measuring end-to-end customer success signals<\/li>\n<\/ul>\n\n\n\n<p><strong>Rule of thumb:<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Endpoint monitoring answers <strong>\u201cIs the API reachable?\u201d<\/strong><\/li>\n\n\n\n<li>Transaction monitoring answers <strong>\u201cCan customers use it?\u201d<\/strong><\/li>\n<\/ul>\n\n\n\n<p>If you\u2019re building broader synthetic checks across your product (not just APIs), that\u2019s part of the <strong><a href=\"https:\/\/www.sslshopper.com\/website-monitoring\/advanced-monitoring\/\">advanced monitoring hub<\/a><\/strong>.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Choosing endpoints to monitor (start with \u201ccustomer success\u201d)<\/h2>\n\n\n\n<p>Don\u2019t monitor everything. Monitor what represents value.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Good \u201ccustomer success\u201d endpoints<\/h3>\n\n\n\n<p>Pick endpoints that are:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>heavily used<\/li>\n\n\n\n<li>business-critical<\/li>\n\n\n\n<li>stable enough to validate<\/li>\n\n\n\n<li>representative of key flows<\/li>\n<\/ul>\n\n\n\n<p>Examples:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>GET \/v1\/me<\/code> (auth + identity)<\/li>\n\n\n\n<li><code>GET \/v1\/subscription<\/code> (billing state)<\/li>\n\n\n\n<li><code>GET \/v1\/projects<\/code> (core object list)<\/li>\n\n\n\n<li><code>POST \/v1\/events<\/code> (write path)<\/li>\n\n\n\n<li><code>GET \/v1\/search?q=\u2026<\/code> (discovery)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Avoid early mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>monitoring only <code>\/health<\/code> (useful, but insufficient)<\/li>\n\n\n\n<li>monitoring endpoints that are too volatile (frequent schema changes)<\/li>\n\n\n\n<li>monitoring endpoints that hit expensive operations without safeguards<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">The \u201chealth endpoint\u201d concept (what it should do)<\/h2>\n\n\n\n<p>A health endpoint is your simplest API signal, but it should be designed carefully.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">A good health endpoint (conceptually)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>checks the app is running<\/li>\n\n\n\n<li>verifies critical dependencies (at least lightly)<\/li>\n\n\n\n<li>returns a fast response (low latency)<\/li>\n\n\n\n<li>can be hit frequently without heavy load<\/li>\n\n\n\n<li>has clear semantics (healthy vs degraded)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common patterns<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Liveness:<\/strong> \u201cprocess is alive\u201d (minimal)<\/li>\n\n\n\n<li><strong>Readiness:<\/strong> \u201ccan serve real traffic\u201d (includes dependency checks)<\/li>\n\n\n\n<li><strong>Dependency health:<\/strong> \u201cDB reachable\u201d \/ \u201ccache reachable\u201d \/ \u201cqueue reachable\u201d (summarized)<\/li>\n<\/ul>\n\n\n\n<p><strong>Important:<\/strong> if your health endpoint always returns 200 even when the DB is down, it will lull you into false confidence. If it\u2019s too heavy, it becomes part of the problem.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Safe auth handling (tokens\/keys hygiene at a high level)<\/h2>\n\n\n\n<p>API monitoring often requires authentication. That\u2019s normal\u2014but your monitoring setup can accidentally become a security liability if you handle tokens poorly.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Token hygiene principles (high-level)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Use a dedicated monitoring identity<\/strong> (service account)\n<ul class=\"wp-block-list\">\n<li>minimal permissions (least privilege)<\/li>\n\n\n\n<li>separate from human admin accounts<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Use short-lived tokens if possible<\/strong>\n<ul class=\"wp-block-list\">\n<li>rotate automatically<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Store secrets securely<\/strong>\n<ul class=\"wp-block-list\">\n<li>in your monitoring tool\u2019s secret vault (if available) or a secure secrets manager<\/li>\n\n\n\n<li>never hardcode in scripts or docs<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Limit blast radius<\/strong>\n<ul class=\"wp-block-list\">\n<li>scope tokens to only the endpoints you monitor<\/li>\n\n\n\n<li>restrict by IP\/network where feasible<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li><strong>Audit access<\/strong>\n<ul class=\"wp-block-list\">\n<li>track who can view\/edit monitors and secrets<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring-specific auth tips<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prefer endpoints that can be checked with a <strong>low-privilege token<\/strong><\/li>\n\n\n\n<li>If your transaction checks need write access, use a <strong>sandbox\/test resource<\/strong> (see below)<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Payload validation (simple examples that catch real failures)<\/h2>\n\n\n\n<p>Payload checks are how you catch \u201cAPI is up but wrong.\u201d<\/p>\n\n\n\n<p>You don\u2019t need complicated validation to get major value. Start with basic assertions:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Simple payload validation patterns<\/h3>\n\n\n\n<p><strong>1) Field existence<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>\u201cResponse includes <code>user.id<\/code> and <code>user.email<\/code>\u201d<\/li>\n\n\n\n<li>\u201cResponse includes <code>items<\/code> array\u201d<\/li>\n<\/ul>\n\n\n\n<p><strong>2) Field type\/shape<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>\u201c<code>items<\/code> is an array\u201d<\/li>\n\n\n\n<li>\u201c<code>created_at<\/code> is an ISO timestamp string\u201d<\/li>\n\n\n\n<li>\u201c<code>total<\/code> is a number\u201d<\/li>\n<\/ul>\n\n\n\n<p><strong>3) Semantic sanity checks<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>\u201c<code>status<\/code> is one of {active, trialing, canceled}\u201d<\/li>\n\n\n\n<li>\u201c<code>count<\/code> is &gt;= 0\u201d<\/li>\n\n\n\n<li>\u201c<code>plan<\/code> is not null\u201d<\/li>\n<\/ul>\n\n\n\n<p><strong>4) Error object validation<\/strong><br>Sometimes \u201cup\u201d means your API is returning structured errors correctly:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>\u201cIf error, response includes <code>error.code<\/code> and <code>error.message<\/code>\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Payload-check pseudo examples (no code)<\/h3>\n\n\n\n<p><strong>Example A: Authenticated identity<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Request: <code>GET \/v1\/me<\/code> with monitoring token<\/li>\n\n\n\n<li>Validate: response includes <code>id<\/code>, <code>email<\/code>, <code>role<\/code><\/li>\n\n\n\n<li>Alert if: 401\/403, missing fields, or latency above threshold<\/li>\n<\/ul>\n\n\n\n<p><strong>Example B: List endpoint that represents \u201ccore usage\u201d<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Request: <code>GET \/v1\/projects?limit=1<\/code><\/li>\n\n\n\n<li>Validate: response includes <code>projects<\/code> array and <code>projects[0].id<\/code> (if any exist)<\/li>\n\n\n\n<li>Alert if: 5xx, empty schema, or unexpected response shape<\/li>\n<\/ul>\n\n\n\n<p><strong>Example C: Write + read confirmation (transaction monitoring)<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Request 1: <code>POST \/v1\/events<\/code> (to a test project)<\/li>\n\n\n\n<li>Validate: returns <code>event_id<\/code><\/li>\n\n\n\n<li>Request 2: <code>GET \/v1\/events\/{event_id}<\/code><\/li>\n\n\n\n<li>Validate: returns matching <code>event_id<\/code> and expected fields<\/li>\n\n\n\n<li>Alert if: write returns 200 but read can\u2019t find it (common eventual consistency issues)<\/li>\n<\/ul>\n\n\n\n<p><strong>Safety note:<\/strong> if you do write checks, write only into <strong>test\/sandbox resources<\/strong> that won\u2019t trigger real customer notifications, billing, or workflows.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Rate limit awareness (how monitoring can accidentally cause incidents)<\/h2>\n\n\n\n<p>API monitoring generates traffic. If you don\u2019t design it with rate limits in mind, you can:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>consume your own quota<\/li>\n\n\n\n<li>trigger automated blocks<\/li>\n\n\n\n<li>confuse analytics and alerting<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Best practices for rate limits<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Know your limits:<\/strong> per-token, per-IP, per-route<\/li>\n\n\n\n<li><strong>Separate monitoring tokens<\/strong> from customer tokens<\/li>\n\n\n\n<li><strong>Use low-frequency checks<\/strong> for expensive endpoints<\/li>\n\n\n\n<li><strong>Prefer lightweight endpoints<\/strong> for frequent checks (<code>\/health<\/code>, \u201cme\u201d endpoints)<\/li>\n\n\n\n<li><strong>Stagger checks<\/strong> across regions (avoid synchronized bursts)<\/li>\n\n\n\n<li><strong>Treat 429 as a first-class signal<\/strong>\n<ul class=\"wp-block-list\">\n<li>It might indicate a true production risk (customers will hit it too)<\/li>\n\n\n\n<li>Or it might mean your monitoring configuration is too aggressive<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Monitoring dependencies (and why \u201cup\u201d still fails)<\/h2>\n\n\n\n<p>Your API is often a coordinator of dependencies:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>database<\/li>\n\n\n\n<li>cache<\/li>\n\n\n\n<li>queue<\/li>\n\n\n\n<li>search<\/li>\n\n\n\n<li>third-party services (payments, email, maps, auth)<\/li>\n<\/ul>\n\n\n\n<p>A dependency can degrade and cause:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>increased latency<\/li>\n\n\n\n<li>partial failures<\/li>\n\n\n\n<li>empty data responses<\/li>\n\n\n\n<li>increased error rates<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Practical dependency monitoring approach<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Add targeted checks for the most critical dependencies:\n<ul class=\"wp-block-list\">\n<li>DNS and certificate validity<\/li>\n\n\n\n<li>third-party API availability (at least one endpoint)<\/li>\n\n\n\n<li>internal services (if microservices)<\/li>\n<\/ul>\n<\/li>\n\n\n\n<li>Tag alerts by dependency so routing is clear:\n<ul class=\"wp-block-list\">\n<li><code>service:api<\/code><\/li>\n\n\n\n<li><code>dependency:payments<\/code><\/li>\n\n\n\n<li><code>dependency:auth<\/code><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\n\n\n<p>When you scale routing and escalation, integrations matter: <strong><a href=\"https:\/\/www.sslshopper.com\/website-monitoring\/uptime-monitoring-integrations\/\">integrations<\/a><\/strong>.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">Tie API monitoring to SLOs and error budgets (so it changes behavior)<\/h2>\n\n\n\n<p>Monitoring becomes powerful when it connects to reliability goals.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What to measure for APIs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>availability (success rate)<\/li>\n\n\n\n<li>latency (p95 or threshold breaches)<\/li>\n\n\n\n<li>correctness (payload validation pass rate)<\/li>\n\n\n\n<li>rate limiting (429 rate)<\/li>\n\n\n\n<li>dependency error rate<\/li>\n<\/ul>\n\n\n\n<p>Then define:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>an SLO (e.g., \u201c99.9% of requests to \/v1\/me succeed under 500ms\u201d)<\/li>\n\n\n\n<li>an error budget (how much failure you can tolerate)<\/li>\n\n\n\n<li>an MTTR target (how fast you recover)<\/li>\n<\/ul>\n\n\n\n<p>If you report to stakeholders, anchor this in real definitions: <strong><a href=\"https:\/\/www.sslshopper.com\/website-monitoring\/uptime-metrics-sla-slo-mttr\/\">uptime metrics<\/a><\/strong>.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">A practical starter plan for API uptime monitoring<\/h2>\n\n\n\n<p>If you want a plan you can implement quickly:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Starter (today)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Monitor <strong>\/health<\/strong> (fast availability + latency)<\/li>\n\n\n\n<li>Monitor <strong>one authenticated \u201ccustomer success\u201d endpoint<\/strong> with payload validation<\/li>\n\n\n\n<li>Route alerts into Slack\/Teams + escalation path<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Intermediate (next)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Add a simple transaction (auth \u2192 read \u2192 write test \u2192 confirm)<\/li>\n\n\n\n<li>Add multi-region checks (2\u20133 regions)<\/li>\n\n\n\n<li>Add dedupe\/grouping and maintenance suppression<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Advanced<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Per-endpoint SLOs and error budgets<\/li>\n\n\n\n<li>Dependency-specific alerts<\/li>\n\n\n\n<li>Automated incident creation via webhooks\/on-call tools<\/li>\n\n\n\n<li>Canary releases tied to monitoring signals<\/li>\n<\/ul>\n\n\n\n<p>This progression aligns with the broader <strong><a href=\"https:\/\/www.sslshopper.com\/website-monitoring\/advanced-monitoring\/\">advanced monitoring hub<\/a><\/strong>.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\">CTA: Monitor one endpoint that represents real customer success<\/h2>\n\n\n\n<p>If your monitoring only checks <code>\/health<\/code>, you\u2019re missing the failures customers notice first.<\/p>\n\n\n\n<p><strong>CTA:<\/strong> Monitor <strong>one endpoint that represents real customer success<\/strong> (auth + core data) and add <strong>basic payload validation<\/strong>. That single step is the fastest upgrade from \u201cAPI is up\u201d to \u201cAPI is working.\u201d<\/p>\n","protected":false},"excerpt":{"rendered":"<p>[1,315 words, 7 minute read time] If you run a SaaS product, your API is the product\u2014at least for some percentage of customers. And APIs fail in a way that classic \u201cping the server\u201d monitoring simply won\u2019t catch: APIs can be \u201cup\u201d but failing\u2014validate what matters. This guide explains API uptime monitoring for technical teams: &#8230; <a title=\"API Uptime Monitoring: Endpoints, Auth, Rate Limits, Payload Checks\" class=\"read-more\" href=\"https:\/\/www.sslshopper.com\/website-monitoring\/api-uptime-monitoring\/\" aria-label=\"Read more about API Uptime Monitoring: Endpoints, Auth, Rate Limits, Payload Checks\">Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[108],"tags":[],"class_list":["post-5520","post","type-post","status-publish","format-standard","hentry","category-guides"],"_links":{"self":[{"href":"https:\/\/www.sslshopper.com\/website-monitoring\/wp-json\/wp\/v2\/posts\/5520","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.sslshopper.com\/website-monitoring\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.sslshopper.com\/website-monitoring\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.sslshopper.com\/website-monitoring\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.sslshopper.com\/website-monitoring\/wp-json\/wp\/v2\/comments?post=5520"}],"version-history":[{"count":2,"href":"https:\/\/www.sslshopper.com\/website-monitoring\/wp-json\/wp\/v2\/posts\/5520\/revisions"}],"predecessor-version":[{"id":5580,"href":"https:\/\/www.sslshopper.com\/website-monitoring\/wp-json\/wp\/v2\/posts\/5520\/revisions\/5580"}],"wp:attachment":[{"href":"https:\/\/www.sslshopper.com\/website-monitoring\/wp-json\/wp\/v2\/media?parent=5520"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.sslshopper.com\/website-monitoring\/wp-json\/wp\/v2\/categories?post=5520"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.sslshopper.com\/website-monitoring\/wp-json\/wp\/v2\/tags?post=5520"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}