API and MCP

Workspace API keys let Cursor, Claude Code, and other clients manage monitors in an existing TraceWise account. Create a key in Dashboard → Settings → API keys. The full tw_ secret is shown once. TraceWise stores only its SHA-256 hash.

For MCP installation, all 16 tools, scopes, rate limits, and troubleshooting, see the MCP documentation. For the embeddable React status widget, see the Status component. npm package: @razorsoft/tracewise-mcp.

Quick start (Cursor remote)

{
  "mcpServers": {
    "tracewise": {
      "url": "https://www.tracewise.dev/api/mcp",
      "headers": {
        "Authorization": "Bearer tw_your_key"
      }
    }
  }
}

Stdio clients can run npx -y @razorsoft/tracewise-mcp with TRACEWISE_API_KEY. Full examples are on the MCP docs page.

Scopes

monitors:read, monitors:write
checks:run
incidents:read
status:read, status:write

Existing keys keep their original scopes. Create a new key when you need status-page or badge permissions.

MCP tools (14)

list_monitors
create_monitor
get_monitor
update_monitor
delete_monitor
get_monitor_status
get_monitor_history
get_uptime_summary
run_monitor_check
list_incidents
list_status_pages
get_status_page
create_status_page
update_status_page
delete_status_page
get_status_badge

REST API

Send Authorization: Bearer tw_…. Responses use { "data": ... } or { "error": { "code", "message" } }. Authenticated REST and MCP share the same quotas (10/min per key; 100/hour and 500/day per workspace, plus operation-specific limits). Plan monitor caps, minimum intervals, URL safety checks, and duplicate URLs match the dashboard.

curl -s https://www.tracewise.dev/api/v1/monitors \
  -H "Authorization: Bearer tw_your_key"

GET    https://www.tracewise.dev/api/v1/monitors
POST   https://www.tracewise.dev/api/v1/monitors
GET    https://www.tracewise.dev/api/v1/monitors/:id
PATCH  https://www.tracewise.dev/api/v1/monitors/:id
DELETE https://www.tracewise.dev/api/v1/monitors/:id
GET    https://www.tracewise.dev/api/v1/monitors/:id/status
GET    https://www.tracewise.dev/api/v1/monitors/:id/history
GET    https://www.tracewise.dev/api/v1/monitors/:id/uptime
POST   https://www.tracewise.dev/api/v1/monitors/:id/check
GET    https://www.tracewise.dev/api/v1/incidents
GET    https://www.tracewise.dev/api/v1/status-pages
POST   https://www.tracewise.dev/api/v1/status-pages
GET    https://www.tracewise.dev/api/v1/status-pages/:id
PATCH  https://www.tracewise.dev/api/v1/status-pages/:id
DELETE https://www.tracewise.dev/api/v1/status-pages/:id
GET    https://www.tracewise.dev/api/v1/status-badge

A key can only see its own workspace. Pass ?url= on the monitors list endpoint to look up an existing monitor before creating one. A new status page starts with no monitors selected. The original page, whose id matches the workspace, can be edited but not deleted.

Monitor diagnostics

GET /api/v1/monitors/:id and GET /api/v1/monitors/:id/status add a diagnostic object from the latest stored check. Status also adds consecutiveFailures, consecutiveSuccesses, and incident (id, openedAt, failureCount) while an incident is open. The monitor list is unchanged.

diagnostic includes checkedAt, result (success or failure), status, classification, category, code, httpStatus, expectedStatusCodes, durationMs, timeoutMs, stages, reason, and confidence. Unavailable measurements are null. reasonis regenerated from TraceWise's known diagnostic templates using measured fields — not stored free text — and is guidance, not a guaranteed root cause.

category is dns, connection, tls, http, timeout, unknown, or null when the check did not fail at a named layer (healthy or slow). stages reports dnsResolved, connected, tlsValid, httpResponded, and redirectCount. TraceWise does not return certificate details, DNS answers, response headers, or response bodies.

History (GET /api/v1/monitors/:id/history) adds category, code, httpStatus, classification, and stages on each check. The default limit stays 50 and the maximum stays 200, still inside the plan retention window.

GET /api/v1/incidents returns the incident id, monitor, status, open and resolve times, latestStatusCode, failureCount, and summary. summary is rebuilt from those fields. Stored incident text, including historical exception messages, is not returned, and latestError is omitted. These fields stay on authenticated routes and are not part of the public status page.