Website monitoring API. Uptime and 90-day site alerts over REST and MCP, included in your plan.

Endpoints and MCP tools for uptime and site alerts

The uptime endpoints read the 30-minute homepage checker, and alerts reads the site's 90-day event log. You can call every endpoint over POST with a JSON body or over GET with query parameters. Grab your personal API key on the MCP page in the app and send it as a Bearer token. Every call is read-only. Your key allows 60 calls a minute across REST and the MCP server together.

Anyone on a site, guests included, can call the uptime endpoints when Uptime is on for their role, while alerts.summary and alerts.feed need role user or higher and return HTTP 403 to guests.

A real uptime.status call and response

Send your API key in the Authorization header and site_id in the JSON body, and the answer comes back under data and meta.

curl -X POST https://app.marketingtracer.com/rest/v1/uptime.status \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"site_id": "YOUR_SITE_ID"}'

{
  "data": {
    "enabled": true,
    "url": "https://example-site.nl/",
    "state": "up",
    "up_since": "2026-10-27T23:30:03Z",
    "down_since": null,
    "last_check_at": "2026-10-31T23:00:08Z",
    "certificate_expires_at": "2027-01-01T13:27:24Z",
    "uptime_7d_pct": 100,
    "uptime_30d_pct": 100,
    "response_ms_median_7d": 209,
    "incidents_30d": 1
  },
  "meta": {
    "site_id": "YOUR_SITE_ID"
  }
}

Endpoints, arguments and field descriptions

Every endpoint is a POST with a JSON body; reading endpoints also take a GET with the same arguments in the query string. Send your API key as Authorization: Bearer YOUR_API_KEY. Every answer is {"data": …, "meta": {…}}: meta.site_id always, meta.next_cursor and meta.total for a list, meta.period where the endpoint covers a period. An error is {"error": {"code", "message"}} with the HTTP status: 400 invalid_argument, unknown_argument or missing_argument; 401 not_authenticated; 403 no_access or tool_off; 404 not_found; 429 rate_limited. The machine-readable version is openapi.json.

uptime.status

POST /rest/v1/uptime.status · MCP tool get_uptime_status

Returns the uptime monitor of one site: whether it is on, the checked address (the homepage), the current state, since when it is up or down, the last check, when the SSL certificate expires, the share of checks that were not down over 7 and 30 days, the median response time over 7 days and the number of incidents in 30 days. Values are null while the monitor has no checks yet.

Arguments

Example request

curl -X POST https://app.marketingtracer.com/rest/v1/uptime.status \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"site_id":"YOUR_SITE_ID"}'

Example response · brabbels.com, 1 November 2026: up since the firewall rule was fixed on 28 October.

{
  "data": {
    "enabled": true,
    "url": "https://example-site.nl/",
    "state": "up",
    "up_since": "2026-10-27T23:30:03Z",
    "down_since": null,
    "last_check_at": "2026-10-31T23:00:08Z",
    "certificate_expires_at": "2027-01-01T13:27:24Z",
    "uptime_7d_pct": 100,
    "uptime_30d_pct": 100,
    "response_ms_median_7d": 209,
    "incidents_30d": 1
  },
  "meta": {"site_id": "YOUR_SITE_ID"}
}

Response fields · in data:

uptime.incidents

POST /rest/v1/uptime.incidents · MCP tool get_uptime_incidents

Returns the incidents of the last 30 days, newest first: each run of checks in a row that were not up, with when it started and ended, how long it took, the worst outcome and the HTTP status or error of that check. One failed round already counts here; the site is only marked down (and alerts are sent) after two in a row. An ongoing incident has no end.

Arguments

Example request

curl -X POST https://app.marketingtracer.com/rest/v1/uptime.incidents \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"site_id":"YOUR_SITE_ID"}'

Example response · The firewall challenge of 26-27 October (403, blocked), before the Skip rule moved to the top of the Cloudflare rules.

{
  "data": [
    {
      "started_at": "2026-10-26T21:22:37Z",
      "ended_at": "2026-10-27T23:30:03Z",
      "ongoing": false,
      "minutes": 1567,
      "outcome": "blocked",
      "rounds": 54,
      "http_status": 403,
      "error": null,
      "firewall": true
    }
  ],
  "meta": {"site_id": "YOUR_SITE_ID", "next_cursor": null, "total": 1}
}

Response fields · data is a list; each item has:

uptime.checks

POST /rest/v1/uptime.checks · MCP tool get_uptime_checks

Returns every check of the last 7 days, newest first, with its outcome and response time (time to first byte). The response time is null when the check got no answer.

Arguments

Example request

curl -X POST https://app.marketingtracer.com/rest/v1/uptime.checks \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"site_id":"YOUR_SITE_ID"}'

Example response · Shortened to two checks; the real answer had 246.

{
  "data": [
    {"at": "2026-10-31T22:30:06Z", "outcome": "up", "response_ms": 220},
    {"at": "2026-10-31T22:00:07Z", "outcome": "up", "response_ms": 273}
  ],
  "meta": {"site_id": "YOUR_SITE_ID", "next_cursor": null, "total": 246}
}

Response fields · data is a list; each item has:

alerts.feed

POST /rest/v1/alerts.feed · MCP tool get_alerts_feed

Returns everything that happened on one site in the last 90 days, newest first, one row per event: outages, SSL and https problems, Core Web Vitals that got worse, and every change the SEO scan found on a page (a new problem, a fixed one, a changed title, H1, meta description or status). The same rows as the Meldingen page, independent of who gets which alert by mail or Slack. Page through with cursor.

Arguments

Example request

curl -X POST https://app.marketingtracer.com/rest/v1/alerts.feed \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"site_id":"YOUR_SITE_ID","kind":"seo","limit":2}'

Example response · Two SEO rows; pages that came back after the firewall fix.

{
  "data": [
    {
      "id": "6ae67516bf737c062606238a",
      "at": "2026-10-31T23:00:00Z",
      "kind": "seo",
      "type": "seo",
      "rule": "status_change",
      "label": "changed",
      "text": "Now returns 200 (was 403)",
      "url": "https://www.example-site.nl/pregnancy/work/risk-assessment",
      "open": false
    },
    {
      "id": "6ae5fa7c532767cc8602b59b",
      "at": "2026-10-30T23:00:00Z",
      "kind": "seo",
      "type": "seo",
      "rule": "status_change",
      "label": "problem",
      "text": "Now returns 410 (was 403)",
      "url": "https://www.example-site.nl/pregnancy/fun/spa-treatment",
      "open": false
    }
  ],
  "meta": {
    "site_id": "YOUR_SITE_ID",
    "next_cursor": "eyJwYyI6WzE3OTM0MDEyMDAwMDAsIjZhZTVmYTdjNTMyNzY3Y2M4NjAyYjU5YiJdfQ==",
    "total": 2
  }
}

Response fields · data is a list; each item has:

alerts.summary

POST /rest/v1/alerts.summary · MCP tool get_alerts_summary

Returns how many events the site had per kind in the last 90 days (the rows of alerts.feed) and what is still going on now: an outage, a blocked check, an SSL or https problem, at most 5, newest first.

Arguments

Example request

curl -X POST https://app.marketingtracer.com/rest/v1/alerts.summary \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"site_id":"YOUR_SITE_ID"}'

Example response · Nothing open; 426 SEO changes in 90 days.

{
  "data": {
    "days": 90,
    "total": 426,
    "by_kind": {"uptime": 0, "sitecheck": 0, "seo": 426, "cwv": 0},
    "open": []
  },
  "meta": {"site_id": "YOUR_SITE_ID"}
}

Response fields · in data: