Getting Started Guide

Everything you need to start monitoring your APIs with FlareCanary.

Adding an endpoint

An endpoint is any HTTP API that returns JSON. FlareCanary polls it on a schedule, captures the response schema, and alerts you when the structure changes.

Adding an MCP server

FlareCanary can monitor Model Context Protocol (MCP) servers for tool catalog changes — tools added, removed, or input schemas modified.

Setting up authentication headers

Many APIs require authentication. FlareCanary sends your headers with every poll request and encrypts sensitive values at rest.

Using the Header Helper

Below the headers textarea, click Header Helper to expand a guided form. Choose your auth type:

• Bearer Token — Paste your token. FlareCanary generates {"Authorization": "Bearer your-token"}.
• Basic Auth — Enter username and password. FlareCanary Base64-encodes them into the correct header.
• API Key — Specify the header name (e.g. X-API-Key) and value. Useful for services that use custom header-based auth.

The helper merges with any existing headers — it won't overwrite other headers you've already set.

Manual JSON entry

You can also type headers directly as a JSON object:

{
  "Authorization": "Bearer sk_live_abc123",
  "X-Custom-Header": "my-value"
}

Understanding drift alerts

When FlareCanary detects a change in an API's response schema, it creates a drift event and optionally sends an alert.

Severity levels

Drift event lifecycle

Each drift event moves through three states:

• New — Just detected. Triggers alert notifications.
• Acknowledged — Your team has reviewed it. Silences repeat notifications for this event.
• Resolved — The drift has been addressed (e.g. you updated your code to handle the change).

Setting up alert destinations

Go to Dashboard → Alerts to add notification destinations:

• Email — Enter an email address to receive styled HTML alerts with severity, endpoint info, and change details.
• Webhook (Pro+) — Provide a URL to receive JSON payloads. Works with Slack, PagerDuty, or any HTTP endpoint.

Alerts can be global (all endpoints) or per-endpoint (scoped to a specific subscription). You can also disable drift alerts for individual endpoints from the endpoint detail page.

Reading results and diffs

Endpoint detail page

Click any endpoint in your dashboard to see its detail page. The layout adapts based on whether it's a REST or MCP endpoint.

REST endpoints

• Schema — A collapsible tree view of the current response structure with type badges for each field.
• Drift History — A timeline of all detected changes with severity badges and acknowledge/resolve actions.
• Response Time — An interactive chart showing latency over 24h, 7d, or 30d with p50/p95/p99 statistics.
• Status Codes — Distribution of HTTP status codes, redirect tracking, and response size stats.
• Uptime — A 30-day uptime bar showing daily availability as a color-coded visualization.
• SSL — Certificate status, issuer, and days until expiry (for HTTPS endpoints).

MCP server endpoints

MCP endpoints show a specialized layout with full monitoring parity:

• MCP Stats — Uptime percentage, average/p95 response time, error rate, tool count, and server name at a glance.
• Response Time Chart — Same interactive latency chart as REST endpoints, tracking MCP handshake and tool listing times.
• JSON-RPC Error Chart — Distribution of JSON-RPC error codes (e.g. -32601 Method not found, -32603 Internal error) and connection-level failures (timeouts, auth failures) over time.
• Tool Catalog — The full list of tools discovered from the MCP server, with their input schemas. This is the baseline used for drift detection.
• Drift History — Tool-level changes: tools added, removed, descriptions changed, or input schemas modified.

Reading a schema diff

When you click on a drift event, the schema diff viewer shows a side-by-side comparison of the previous and current schemas:

• Green highlights indicate added fields — new data in the response.
• Red highlights indicate removed fields — data your code may depend on.
• Yellow highlights indicate type changes — a field's data type changed (e.g. number to string).

Changes are reported with dot-notation paths (e.g. data.user.email) so you can pinpoint exactly where in the response structure the change occurred.

MCP tool diffs

For MCP server endpoints, drift events show tool-level changes instead of field-level changes:

• Tool added/removed — A tool appeared in or disappeared from the server's catalog.
• Description changed — A tool's description text was modified.
• Input schema changed — A tool's parameters changed, with expandable field-level details.

Refreshing the baseline

If an API change is expected (e.g. after a planned migration), you can click Refresh Baseline on the endpoint detail page. This re-polls the endpoint and sets the current response as the new baseline, clearing the slate for future comparisons.

Metric alerts

Available on Starter plans and above, metric alerts let you set threshold rules on performance data.

• Response time — Alert when latency exceeds a threshold (e.g. >500ms for 3 consecutive checks).
• HTTP error codes (REST) — Choose Any HTTP error (4xx/5xx) for a catch-all, or pick one or more specific codes (400, 401, 403, 404, 429, 500, 502, 503, 504, or a custom code) from a checklist. The alert fires if any selected code is observed.
• JSON-RPC errors (MCP) — Choose Any JSON-RPC error or select specific error codes (-32700, -32600, -32601, -32602, -32603, or a custom code).
• SSL expiry — Alert when a certificate is expiring within a configurable number of days.
• Response size — Alert when payload size exceeds a threshold.
• Availability — Alert when uptime drops below a percentage.
• Consecutive intervals — The rule must breach for N consecutive polls before firing (default 3). This prevents noisy alerts from one-off spikes.
• Cooldown — After firing, repeat alerts are suppressed for a configurable period (default 60 minutes).
• Auto-resolve — Optionally get notified when the condition heals.

Create metric alert rules from the endpoint detail page under the Alert Rules section.

Working with organizations

Organizations let teams share endpoints, alerts, and settings.

• Personal org — Created automatically when you sign up. Your endpoints live here by default.
• Create an org — Go to Dashboard → New Organization and set a name and slug.
• Invite members — From Org Settings → Members, invite by email. Assign roles: Viewer (read-only), Editor (manage endpoints), or Admin (full control).
• Switch orgs — Use the org switcher dropdown in the dashboard nav to switch between your organizations.
• Status pages — Admins can enable a public status page for the org at /status/your-org-slug, showing real-time endpoint health, uptime, and SSL status.

Public status pages

Share real-time endpoint health with your team or customers via a hosted status page.

• Enable — Go to Org Settings and toggle Public Status Page on. Set an optional description.
• Access — Your status page is available at /status/your-org-slug. When public, anyone can view it without signing in. When private, only org members can access it.
• What it shows — Overall system status, per-endpoint health (operational, degraded, or down), 30-day uptime bars, average response times, and SSL certificate status.
• API access — The status page data is also available via GET /api/status/your-org-slug for programmatic integration. See the API reference.