Relvato
任何網站的監控,對WordPress與WooCommerce最深入:新增網站、執行檢查、讀取結果並取得修復提示。
託管 MCP 伺服器
npx add-mcp 'https://app.relvato.com/api/mcp'可安裝到 Claude Code、Codex、Cursor 等客戶端
文件
Quick start
Every request authenticates with an API key you create in the app. Point curl, your CI, or any HTTP client at https://app.relvato.com/api/v1.
# 1 — Confirm your key works and see the endpoints
curl https://app.relvato.com/api/v1 \
-H "Authorization: Bearer rlv_your_key"
# 2 — List the sites Relvato monitors for you
curl https://app.relvato.com/api/v1/sites \
-H "Authorization: Bearer rlv_your_key"
# 3 — Read recent runs (optionally scoped to one site)
curl "https://app.relvato.com/api/v1/runs?limit=10" \
-H "Authorization: Bearer rlv_your_key"
# 4 — One run in detail, then the fix brief Relvato's AI would answer
curl https://app.relvato.com/api/v1/runs/RUN_ID \
-H "Authorization: Bearer rlv_your_key"
curl https://app.relvato.com/api/v1/runs/RUN_ID/fix-prompt \
-H "Authorization: Bearer rlv_your_key"
# 5 — Run a site's monitors now (full-access key): all of them…
curl -X POST https://app.relvato.com/api/v1/sites/SITE_ID/scan \
-H "Authorization: Bearer rlv_your_key"
# …or one group
curl -X POST https://app.relvato.com/api/v1/sites/SITE_ID/scan \
-H "Authorization: Bearer rlv_your_key" \
-H "Content-Type: application/json" \
-d '{"group": "security"}'
Running monitors from GitHub after a deploy? The GitHub Action starts the scan, waits for the runs and fails the job when a monitor finds a problem: Website monitoring GitHub Action →
Want alerts in chat apps, automation in Zapier or n8n, or a GitHub Action instead of a webhook? See: Website monitoring integrations →
Authentication
Send your key on every request as Authorization: Bearer rlv_your_key (an x-api-key header works too). A missing, revoked, or unknown key returns 401.
Create and revoke keys under API access in the app. Keys start with rlv_ and are shown once at creation. Each key is read-only (everything that reads: sites, health, performance, runs, monitors, updates, activity, fix briefs, alert settings) or full access (also add and configure sites and monitors, run them, review results and apply proposed fixes). Keys made before scopes existed have full access. Treat keys like a password.
REST endpoints
Every endpoint is scoped to the account behind the key and returns JSON. Base URL https://app.relvato.com/api/v1. The POST endpoints need a full-access key, take a JSON body with the same field names as the MCP tool for the same job, and answer exactly what that tool answers.
| Method | Endpoint | Description |
|---|---|---|
| GET | /api/v1 | Confirms the key and lists the available endpoints. |
| GET | /api/v1/sites | Lists the websites Relvato monitors for you, each with platform (wordpress or other), ready (ownership proven) and disabled. |
| POST | /api/v1/sites | Adds a site (url, platform wordpress or other, optional name) and returns its setup; 201 when added, 200 with the existing site on the same domain. |
| GET | /api/v1/sites/:id/overview | A site's health verdict: what needs attention, each monitor's latest run and plan usage. |
| GET | /api/v1/sites/:id/settings | A site's settings — never secret values. |
| GET | /api/v1/sites/:id/health | Health now and over time (?range=28|90|182), group briefings, probe uptime. |
| GET | /api/v1/sites/:id/performance | Lab and real-user Web Vitals, what slows the site, the top fixes. |
| GET | /api/v1/sites/:id/activity | The WordPress activity log (?filter,?search,?days,?limit). |
| GET | /api/v1/sites/:id/updates | WordPress auto-update windows, held versions, safe updates, hardening. |
| GET | /api/v1/sites/:id/quarantine | Quarantine mode: the active session, its changes, past sessions. |
| GET | /api/v1/checks/:id | One monitor in full: schedule, its own settings, ignored findings, latest run. |
| GET | /api/v1/notifications | The dashboard's notifications. |
| GET | /api/v1/runs | Recent runs, newest first — optional siteId, checkId, status, before (paging) and limit (1–100). Each run says whether it's finished, its outcome (ok / issue / not-run / pending) and, for an issue, its severity. |
| GET | /api/v1/runs/:id | One run in detail: steps, warnings, findings and metrics (compacted when large). |
| GET | /api/v1/runs/:id/fix-prompt | For a run that found a problem: the brief Relvato's own AI answers — stack, what changed, the error and evidence. |
| GET | /api/v1/alert-settings | Who is told about what: frequency, severity, channels and routing. Never URLs or secrets. |
| GET | /api/v1/hooks | Your event subscriptions: host, events, filter and status — never the URL or the secret. |
| POST | /api/v1/hooks | Subscribes a URL to events (check.failed, check.recovered, quarantine.change), with an optional filter. Pro and up, full-access key; returns the signing secret once. |
| DELETE | /api/v1/hooks/:id | Unsubscribes. 204, also when it's already gone. |
| POST | /api/v1/hooks/test | Sends a signed test event ("test": true) to this key's subscriptions, or to one with id, built to pass each one's filter. Nothing about the subscription changes. |
| GET | /api/v1/events | Recent check.failed and check.recovered events (?type,?siteId,?limit), in the shape a subscription receives. |
| GET | /api/v1/metrics | Prometheus metrics in the text format for your sites and monitors (?siteId for one site): whether each monitor's latest run passed, uptime, heartbeats, SSL and domain expiry, runs used. Any key; cached for 30 seconds. |
| POST | /api/v1/sites/:id/scan | Runs a site's monitors now and returns the run ids: all of them, or only one group when the JSON body sets group (for example security). Needs a full-access key; counts against your monthly run quota. |
| POST | /api/v1/sites/:id/goals | Adds the monitors that cover the goals you list (flows, security, search, design, compliance, speed, domain, custom, ai). |
| POST | /api/v1/sites/:id/groups/:group/pause | Pauses one monitoring group, such as security, for duration 1h, 24h or until resumed. |
| POST | /api/v1/sites/:id/groups/:group/resume | Resumes a paused monitoring group now. |
| POST | /api/v1/sites/:id/heartbeats | Creates a heartbeat for a job (name, optional periodSec, graceSec or cron) and returns its ping URL. |
Example: list sites
{
"sites": [
{
"id": "st_1a2b3c",
"name": "style4street",
"url": "https://style4street.com",
"connectionType": "wordpress",
"platform": "wordpress",
"ready": true,
"disabled": false
}
]
}
Example: recent runs
A run that failed but was later resolved (baseline accepted or ignored) reports status: "passed" with resolved: true. Each run also says whether it's finished, its outcome (ok, issue, not-run or pending) and, for an issue, its severity.
{
"runs": [
{
"id": "rn_9f8e7d",
"siteId": "st_1a2b3c",
"checkId": "ck_4d5e6f",
"journey": "checkout",
"checkName": "Checkout",
"status": "passed",
"resolved": false,
"finished": true,
"outcome": "ok",
"trigger": "schedule",
"startedAt": "2026-08-31T09:15:00.000Z",
"durationMs": 4210,
"error": null,
"warning": null
}
]
}
Example: one run in detail
Findings come in metrics.items. A large run is compacted rather than cut: long series become summaries, and what was left out is listed in metricsTrimmed — the headline and findings are always kept.
{
"runId": "rn_9f8e7d",
"runUrl": "https://app.relvato.com/runs/rn_9f8e7d",
"check": { "key": "google-search", "name": "Google Search" },
"status": "passed",
"warning": "https://style4street.com/category/topuri/hanorace/ lost 57% of its Google impressions",
"metrics": {
"headline": { "tone": "warn", "text": "🔎 1 thing to review on Google Search (as of 2026-09-24)" },
"items": [
{ "text": "https://style4street.com/category/topuri/hanorace/ lost 57% of its Google impressions — 98 in the 7 days to 2026-09-24, against 226 in an average week before", "tone": "warn" }
],
"search": { "engine": "google", "tiles": [ … ], "dailies": [ { "label": "Impressions per day", "days": 84, "last7Total": 2196, "usualLast7Total": 2583 } ], … }
},
"metricsTrimmed": {
"note": "Large parts were left out to keep this short — the run page has everything.",
"omitted": ["search.dailies (the per-day values — summarized)", "search.tiles[].weekly (the 8 weekly bars)"]
}
}
Example: a run's fix brief
For a run that found a problem, fix-prompt returns the brief Relvato's own AI answers: the site's stack, what changed just before, the error and findings, and for Google / Bing Search the evidence that rules causes out. Hand it to your own model, or read it yourself.
{
"runId": "rn_9f8e7d",
"runUrl": "https://app.relvato.com/runs/rn_9f8e7d",
"hasIssue": true,
"prompt": "# Help me understand a Google Search change on my WordPress site\n\nYou are a senior SEO specialist. … ## Evidence Relvato already has …"
}
Prometheus and Grafana
GET /api/v1/metrics answers in the Prometheus text format (0.0.4), so Prometheus, Grafana or any OpenMetrics scraper can collect your sites and monitors like any other exporter. It works on every plan and with a read-only key; add ?siteId= for one site. The answer is cached for 30 seconds, and each scrape counts as one request toward your rate limit: a 60-second interval uses one a minute.
Every series carries site (the host) and site_id; monitor series add monitor, monitor_id, monitor_key and group. relvato_monitor_up is 1 when a monitor's latest run passed and 0 when it found a problem. When the latest run couldn't run (a firewall blocked Relvato, say), there's no relvato_monitor_up: relvato_monitor_last_outcome with outcome="not-run" is 1 instead, so you can alert on that too.
Also exposed: relvato_monitor_enabled, relvato_monitor_last_run_timestamp_seconds, relvato_monitor_last_run_duration_seconds, relvato_uptime_up, relvato_uptime_response_time_seconds and relvato_uptime_last_probe_timestamp_seconds (per region), relvato_heartbeat_up, relvato_heartbeat_last_ping_timestamp_seconds, relvato_port_up, relvato_ssl_certificate_expiry_timestamp_seconds, relvato_domain_expiry_timestamp_seconds, relvato_site_info, relvato_site_ownership_proven, relvato_runs_used and relvato_runs_limit. Times are Unix timestamps in seconds, and durations are in seconds.
A scrape looks like this:
# TYPE relvato_monitor_up gauge
relvato_monitor_up{site="style4street.com",site_id="st_1a2b3c",monitor="Guest checkout",monitor_id="ck_4d5e6f",monitor_key="woo-checkout",group="flow"} 1
relvato_monitor_up{site="style4street.com",site_id="st_1a2b3c",monitor="Vulnerability scan",monitor_id="ck_7a8b9c",monitor_key="vuln-scan",group="security"} 0
# TYPE relvato_monitor_last_outcome gauge
relvato_monitor_last_outcome{site="style4street.com",site_id="st_1a2b3c",monitor="Storefront",monitor_id="ck_1f2e3d",monitor_key="storefront",group="flow",outcome="not-run"} 1
# TYPE relvato_monitor_last_run_timestamp_seconds gauge
relvato_monitor_last_run_timestamp_seconds{site="style4street.com",site_id="st_1a2b3c",monitor="Guest checkout",monitor_id="ck_4d5e6f",monitor_key="woo-checkout",group="flow"} 1794214842
# TYPE relvato_uptime_response_time_seconds gauge
relvato_uptime_response_time_seconds{site="style4street.com",site_id="st_1a2b3c",region="eu"} 0.183
relvato_uptime_response_time_seconds{site="style4street.com",site_id="st_1a2b3c",region="us"} 0.412
# TYPE relvato_ssl_certificate_expiry_timestamp_seconds gauge
relvato_ssl_certificate_expiry_timestamp_seconds{site="style4street.com",site_id="st_1a2b3c"} 1799971200
# TYPE relvato_runs_used gauge
relvato_runs_used 412
Save the API key in a file Prometheus can read (or paste it with credentials instead of credentials_file) and add the job:
scrape_configs:
- job_name: relvato
scheme: https
metrics_path: /api/v1/metrics
scrape_interval: 60s
authorization:
type: Bearer
credentials_file: /etc/prometheus/relvato_api_key # holds rlv_your_key
static_configs:
- targets: ["app.relvato.com"]
Then alert when a monitor finds a problem, or when the certificate has less than 14 days left:
groups:
- name: relvato
rules:
- alert: RelvatoMonitorFoundAProblem
expr: relvato_monitor_up == 0
for: 5m
annotations:
summary: "{{ $labels.monitor }} on {{ $labels.site }} found a problem"
- alert: RelvatoCertificateExpiresSoon
expr: relvato_ssl_certificate_expiry_timestamp_seconds - time() < 14 * 86400
annotations:
summary: "The certificate on {{ $labels.site }} expires in less than 14 days"
Datadog's OpenMetrics integration and Grafana Cloud's Prometheus scraping work with the same URL and Authorization: Bearer header.
A full setup walkthrough, with the scrape config and alert rules above: Prometheus website monitoring →
Events: subscribe instead of polling
Instead of polling /api/v1/runs, give Relvato a URL: it POSTs each matching event there as it happens, signed. This is what Zapier, n8n and Make triggers use. Event subscriptions are on Pro and up, need a full-access key, and an account can have 25.
Using Zapier? The Relvato Zapier app, in beta, sets up these subscriptions for its instant triggers and adds actions such as Add Site and Run Monitors Now: Zapier website monitoring →
Using n8n? The n8n-nodes-relvato community node has a Relvato Trigger for these events and a Relvato node with actions such as Add Site and Run Monitors Now: n8n website monitoring →
Using Make? The Relvato Make app, in beta, sets up these subscriptions for its Watch events trigger and adds actions such as Add a site and Run monitors now: Make website monitoring →
check.failed— a monitor went from passing to failing (re-running one that's already failing doesn't send it again). Uptime, heartbeat and port monitors send it when they go down.check.recovered— a monitor passes again after failing. Uptime, heartbeat and port monitors send it when they come back up.quarantine.change— Quarantine mode noticed changes on a site that was just cleaned.
Events follow changes, not every run: a monitor that stays broken doesn't send check.failed again on each failed run, and a passing run sends nothing unless it ends a failure.
Subscriptions don't follow Alert settings — digests, muted sites and the severity threshold are for people. Narrow what you receive with the filter instead: siteId, monitor groups (for example security) and monitor keys (GET /api/v1/checks/:id shows a monitor's key).
Subscribe, list, test, unsubscribe
# Subscribe a URL (full-access key, Pro and up); the answer carries the signing secret, once
curl -X POST https://app.relvato.com/api/v1/hooks \
-H "Authorization: Bearer rlv_your_key" \
-H "Content-Type: application/json" \
-d '{"url": "https://hooks.example.com/relvato", "events": ["check.failed", "check.recovered"], "filter": {"keys": ["uptime"]}}'
# List your subscriptions (the host only, never the URL or the secret)
curl https://app.relvato.com/api/v1/hooks \
-H "Authorization: Bearer rlv_your_key"
# Recent events, in the shape a subscription receives
curl "https://app.relvato.com/api/v1/events?type=check.failed&limit=5" \
-H "Authorization: Bearer rlv_your_key"
# Send a signed test event ("test": true) to this key's subscriptions; {"id": "SUBSCRIPTION_ID"} for one
curl -X POST https://app.relvato.com/api/v1/hooks/test \
-H "Authorization: Bearer rlv_your_key" \
-H "Content-Type: application/json" \
-d '{"type": "check.failed"}'
# Unsubscribe: 204, also when it's already gone
curl -X DELETE https://app.relvato.com/api/v1/hooks/SUBSCRIPTION_ID \
-H "Authorization: Bearer rlv_your_key"
A new subscription answers 201 with its id, host, events, filter, status and the signing secret — shown only this once, so store it. Sending the same URL, events and filter again answers 200 with the existing subscription and no secret, so a retried subscribe doesn't make a second one. Errors: 400 bad_url, bad_events or bad_filter; 403 plan_required (with minPlan) or insufficient_scope for a read-only key; 409 too_many at 25.
{
"id": "8d1f3c52-6a7b-4e0f-9c21-5b7e2d4a9f10",
"host": "hooks.example.com",
"events": ["check.failed", "check.recovered"],
"filter": { "keys": ["uptime"] },
"status": "active",
"lastError": null,
"lastDeliveredAt": null,
"createdAt": "2026-11-01T09:00:00.000Z",
"secret": "whsec_…",
"signature": "Relvato-Signature: t=<unix seconds>,v1=<hex HMAC-SHA256 of \"<t>.<raw body>\"> with this secret"
}
What a subscription receives
The same v1 event as a webhook alert — version, id, type, created_at, site, check, run, quarantine — plus run.outcome (ok, issue or not-run) and run.not_run_reason (for example firewall). It's signed the same way, with the subscription's own secret: Relvato-Signature: t=…,v1=… is an HMAC-SHA256 of the timestamp, a dot and the raw body, sent with the Relvato-Event and Relvato-Delivery headers. Verify the signature as you would for a webhook — one receiver handles both.
{
"version": 1,
"id": "evt_3c9a41f07b2e8d56a1f4c0e9",
"type": "check.failed",
"created_at": "2026-11-01T09:15:04.000Z",
"site": { "id": "st_1a2b3c", "name": "style4street", "url": "https://style4street.com" },
"check": { "key": "uptime", "name": "Uptime", "group": "Uptime", "severity": "high" },
"run": {
"id": "rn_9f8e7d",
"url": "https://app.relvato.com/runs/rn_9f8e7d",
"status": "failed",
"error": "homepage returned HTTP 503",
"failed_step": null,
"trigger": "schedule",
"changes": null,
"outcome": "issue",
"not_run_reason": null
},
"quarantine": null
}
GET /api/v1/events returns the last 30 days' check.failed and check.recovered events, newest first, in exactly that shape and with the same ids as live deliveries — sample data for a trigger, and a way to skip duplicates. Filter with type, siteId and limit (1–100, default 25). Only sites whose ownership is proven have events; with none, the list is empty.
POST /api/v1/hooks/test sends a test event to the subscriptions your API key created — all of them, or one with {"id": "…"} — so you see a sample without waiting for a real failure (Zapier and n8n need one before a trigger goes live). Each gets a real event of the type you choose (or of its first event type), signed with its own secret, with "test": true and a new id every time. It's built to pass the subscription's filter: its site (else your first site, or example.com when you have none) and a monitor from its keys or groups (else uptime). The answer lists each delivery's receiver status and ok under sent, and the subscriptions it left out, with the reason, under skipped. A test never changes a subscription: a failed delivery or a 410 doesn't count. Each delivery counts as one request toward your rate limit, at most 25 per call. Add "delayMs": 3000 (up to 10000) to get an immediate 202 and the events a few seconds later, for a receiver that stores its secret only after your request returns, like n8n's trigger.
A subscription stops when your receiver answers 410 (Relvato deletes it), when 20 deliveries in a row fail (it's disabled — GET /api/v1/hooks shows status: "disabled" and lastError), when the API key that created it is revoked, and when the account moves below Pro (deliveries stop).
Common recipes
| You want to know | events | filter.keys |
|---|---|---|
| Site down | ["check.failed"] | ["uptime"] |
| Site back up | ["check.recovered"] | ["uptime"] |
| New vulnerability | ["check.failed"] | ["vuln-scan", "cms-vulns"] |
| Visual change | ["check.failed"] | ["visual-regression"] |
vuln-scan is the WordPress vulnerability scan; cms-vulns covers Drupal, Joomla, PrestaShop and Magento.
Rate limits
Requests are limited per minute, per account, across REST and MCP combined. Your plan sets the ceiling:
| Plan | Requests / min |
|---|---|
| Free | 30 |
| Pro | 120 |
| Business | 600 |
| Agency | 2,400 |
Every response carries X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset. Over the limit returns 429 with a Retry-After header.
Status codes
| Status | Meaning |
|---|---|
200 | Success. |
400 | The request is missing something or can't be done — the message says what. |
401 | Missing, unknown, or revoked API key. |
403 | The key is read-only and the request would change something or run a scan — or, for event subscriptions, the plan is below Pro (plan_required). |
404 | Site or run not found for this account. |
409 | Site is disabled, or you haven't proven you own it yet (domain not verified, or WordPress plugin never connected). For event subscriptions: the account already has 25 (too_many). |
429 | Rate limit hit, or the monthly run quota is used up. |
MCP server (for AI agents)
Relvato is also a remote Model Context Protocol server with 58 tools, so an agent like Claude can do in a conversation what you'd do in the dashboard: add a site and walk you through connecting it, pick and configure its monitors (down to the pages the visual monitor checks), run them, explain the results and, when you agree, accept an intended change or hand you the link to apply the fix a run proposes in WordPress. Connect it by signing in to Relvato or with an API key; either way it shares the REST API's rate limit. Approving file-integrity, script and DNS changes, who receives alerts, secrets and deleting anything stay in the dashboard.
Running Relvato from Claude, ChatGPT or a coding agent instead of calling the API by hand? See: Agentic website monitoring →
Listed in Claude's Connectors Directory ↗, in ChatGPT ↗ as a plugin, and in the GitHub MCP Registry ↗.
Sign in, no key needed. Add the endpoint as a connector in Claude (claude.ai, Desktop or Claude Code), ChatGPT or VS Code. The client opens Relvato's sign-in; you allow it to read your sites and results and to make changes: add sites and monitors, change schedules and run scans. Sign-in works in clients that support Client ID Metadata Documents; Cursor and Docker's MCP gateway don't yet, so they use an API key.
If you belong to an organization, you pick one of its workspaces on the sign-in screen; your personal workspace isn't offered there. To connect your personal workspace, use an API key.
Things you can ask an agent connected to Relvato:
- “Why did checkout fail on my shop last night, and how do I fix it?”
- “Set up monitoring for example.com and tell me what I need to do to connect it.”
- “Who gets alerted when a Security monitor finds a problem, and on which channels?”
- “Add my pricing and blog pages to the visual monitor, and run it.”
- “How fast is my shop for real visitors, and what's slowing it down?”
Endpoint https://app.relvato.com/api/mcp
| Tool | What it does |
|---|---|
| Set up | |
list_sites | List the account's websites and whether each is ready to run monitors. |
add_site | Add a website and get its setup step: connect the WordPress plugin, or verify the domain. |
verify_site | Check that setup step: the plugin connection, or the domain-verification DNS record or meta tag. |
start_monitoring_for_goals | Pick what matters (checkout, security, search, speed, …) and get the monitors that cover it on your plan. |
list_checks | The monitors you can add to a site: what each catches, whether your plan includes it, and which are recommended. |
add_checks | Add monitors to a site; each one reports added, already there, or why not. |
dismiss_recommendation | Stop recommending a monitor for a site, or bring dismissed recommendations back. |
calibrate_site | WooCommerce: read the store again (a product to buy, checkout type, currency) after it changed. |
verify_vitals_beacon | Check the real-user Web Vitals beacon is installed. |
| Read | |
site_overview | Plain-language health verdict: what needs attention, every monitor with its latest run and schedule, plan usage and, on WordPress, the site's AI abilities. |
get_site_health | Pass rate now and over 30 days, the trend over 28–182 days, each group's briefing, and probe uptime with incidents. |
get_performance | Lab and real-user Core Web Vitals, what slows the site down, and the top fixes with steps. |
get_check | One monitor in full: schedule, its own settings (pages, masks, checkout details, …), ignored findings, its recipe if AI-written, latest run. |
list_runs | Recent runs, newest first — by site, monitor or status, with paging. |
get_run | One run in detail: steps, findings, visual comparisons with image links, the fix it proposes, plugins it suggests updating. |
get_fix_prompt | For a run that found a problem: the same brief Relvato's own AI answers, to reason about the likely cause and fixes. |
get_updates | WordPress: auto-update windows and what they updated or rolled back, held versions, safe updates, hardening. |
get_safe_update | Follow a safe plugin update or deactivation until it passes, breaks a monitor or is undone in WordPress. |
get_quarantine | Quarantine mode: available or not, on until when, every change it saw, past sessions. |
get_activity_log | WordPress: sign-ins, failed sign-ins, accounts, updates, settings and file edits, within your plan's history. |
get_notifications | The dashboard's notifications: failing monitors, plugin or beacon problems, paused channels, billing. |
get_site_settings | A site's settings — what an agent may change and what stays in the dashboard (never secret values). |
get_alert_settings | Who is told about what: frequency, severity, each channel's state and routing — no URLs or secrets. |
get_status_pages | Status pages and client reports: settings only, never a private link or recipients' addresses. |
list_heartbeats | A site's heartbeats (cron jobs that check in): state, schedule, last ping, missed check-ins — and the ping URLs on full access. |
| Configure | |
update_check | Turn a monitor on or off, or change when it runs: schedule, re-runs on WordPress updates, random extra runs. |
pause_monitor_group | Pause a whole monitoring group for 1 hour, 24 hours or until resumed, during maintenance; exactly the monitors it switched off come back on. |
resume_monitor_group | Resume a paused group now; a monitor the plan no longer allows stays off, with the reason. |
update_visual_monitor | Add pages of your own by address to the visual monitor, set masks, devices, browsers and the threshold. |
update_check_settings | A monitor's own settings: checkout details, extra pages to scan, what the site's AI feature must answer, DKIM selectors, … |
add_custom_check | Describe what must be true on a page; Relvato's AI writes the monitor. |
edit_custom_check | Give a custom monitor a new goal or page; the AI writes a new recipe to approve. |
reauthor_custom_check | Answer the AI's question, or have it write a custom monitor's recipe again. |
approve_custom_check | Approve a proposed recipe so the custom monitor runs (interactive recipes need an explicit OK). |
update_site_settings | Pacing, spacing between runs, firewall retry, flaky-monitor recovery, plugin rollback. |
update_alert_settings | Alert timing and minimum severity. Who receives alerts and muting stay in the dashboard. |
add_heartbeat | Create a heartbeat for a cron job or backup and get the URL the job requests when it succeeds. |
update_heartbeat | Rename, reschedule, pause or resume a heartbeat. Deleting stays in the dashboard. |
| Run and act | |
trigger_scan | Run a site's monitors now — all, one group, or one monitor — and get the run ids and about how long they'll take (uses the monthly quota). |
cancel_queued_runs | Stop a site's queued runs; the one already going finishes. |
request_ai_fix | Ask Relvato's AI for a fix suggestion for a failed run (paid plans). |
apply_fix | WordPress: get the link to apply the one-click fix a run proposes — only that fix — in WordPress; Relvato then re-runs the monitor. |
start_safe_update | WordPress: start a vulnerable plugin's update or deactivation, applied in WordPress; Relvato re-checks and offers Undo if anything breaks. |
start_quarantine | After a hack: hourly security runs for 48 hours with plugin updates paused. |
extend_quarantine | Keep quarantine mode on for another 48 hours. |
send_test_alert | Send a test alert by email, Slack or webhook. |
resume_webhook | Turn webhook alerts back on after Relvato paused them for failed deliveries. |
report_false_positive | Tell Relvato's team a result is wrong; it changes nothing on the run. |
| Review results | |
ignore_finding | Stop a finding from counting on a monitor (undoable). Only when you confirm it's expected. |
unignore_finding | Make an ignored finding count again. |
bring_back_run | Bring back a failure Relvato AI set aside as likely noise. |
accept_visual_change | Make this run's screenshot the new baseline for a page (undoable). |
ignore_visual_change | Ignore the area that changed on a page from now on (undoable). |
flag_visual_change_as_problem | Mark a visual change the AI let pass as a failure. |
undo_visual_review | Undo the last visual accept or ignore. |
accept_structure_change | Adopt a page's new structure as its baseline (undoable). |
ignore_structure_change | Ignore specific element changes on a page (undoable). |
undo_structure_review | Undo the last structure accept or ignore. |
In a client that reads an mcp.json, the endpoint is enough — the client asks you to sign in the first time:
{
"mcpServers": {
"relvato": {
"type": "http",
"url": "https://app.relvato.com/api/mcp"
}
}
}
To use an API key instead (a script, a client without sign-in, or your personal workspace while you're in an organization), add the header. A read-only key only gets the read tools:
{
"mcpServers": {
"relvato": {
"type": "http",
"url": "https://app.relvato.com/api/mcp",
"headers": {
"Authorization": "Bearer rlv_your_key"
}
}
}
}
Claude Code plugin
In Claude Code, the Relvato plugin adds the server plus six skills: three for any conversation about your sites, and three for working from your site's repository. Install it from our marketplace, then run /mcp and sign in:
claude plugin marketplace add Relvato/relvato-mcp
claude plugin install relvato@relvato
/relvato:site-healthreports how a site is doing across all its monitors (uptime, user flows, security, speed, SEO, design, domain and compliance) and what needs attention first./relvato:search-trafficexplains the site's Google Search Console and Bing Webmaster Tools numbers against its usual, the pages and queries losing ground, and its SEO integrity./relvato:security-reviewgoes through the security monitors (vulnerable plugins, signs of a hack, changed files, new admins, exposed files) in order of urgency, and what to do first./relvato:setupadds the site this repository deploys, proves you own it (it can add the verification meta tag to your code), picks monitors and starts the first runs./relvato:check-after-deployruns the site's monitors after a deploy, says how long they'll take, and reports what passed and what broke./relvato:fix-failurereads a failed run, finds the cause in your code, makes the smallest fix with your OK, and runs that monitor again.
Perplexity
On a Perplexity Pro, Max or Enterprise plan, add Relvato as a custom connector: Settings → Connectors → + Custom connector → Remote. Use the endpoint above as the MCP server URL and Streamable HTTP as the transport.
For Authentication, choose API key and paste a Relvato API key (create one under API access in the app; a read-only key only gets the read tools). Perplexity's OAuth option doesn't work with Relvato's sign-in yet: it needs the server to register Perplexity automatically, which Relvato doesn't offer.
Webhooks
The API answers when you ask. To be told the moment a monitor finds a problem, add a webhook: Relvato POSTs a signed JSON event to your URL for every alert (Pro and up). Set up a webhook →
Frequently asked questions
Which plans include API and MCP access?
All of them, including Free — only the per-minute rate limit differs. Free allows 30 requests a minute; paid plans allow more.
How do I get a key?
Sign in and open API access in the app. Choose read-only or full access for each key; you can create several and revoke any of them at any time.
What can a read-only key do?
Everything that only reads: sites, health and uptime, performance, runs and monitors, WordPress updates and activity, quarantine, notifications, fix briefs and alert settings — over REST and MCP. An MCP client connected with a read-only key only sees the read tools. Anything that adds, changes, runs or reviews returns 403 and needs a full-access key.
Does triggering a scan use my quota?
Yes. On-demand scans — over REST or MCP — draw from the same monthly run quota as scheduled runs.
Can an agent add sites and change monitors?
Yes — within your plan's limits, under the same rules as the dashboard. It can't skip ownership: a new site only runs once its WordPress plugin is connected or its domain is verified. It can accept or ignore a result only in ways you can undo, and on WordPress hand you only the fix a run proposes, to apply in WordPress → Relvato. Approving file-integrity, script and DNS changes, stopping quarantine mode, choosing who receives alerts, secrets and deletes stay in the dashboard.
Can an AI assistant connect without an API key?
Yes. Claude, ChatGPT and VS Code can sign in to Relvato instead (any client that supports Client ID Metadata Documents can): add the MCP endpoint and follow the sign-in. It has the same rate limit and plan limits as a key. If you belong to an organization, sign-in connects one of its workspaces; use an API key for your personal one.
Does Relvato work with the WordPress Abilities API?
Both ways. The Relvato plugin registers four abilities (site status, monitors, fix brief and run monitors), so an assistant connected to a WordPress site through the MCP Adapter can use Relvato from there. And site_overview lists the abilities every plugin on a WordPress site registers, as the exposure scan last read them: which ones anyone can run, and which can delete data.