# PingChange > Monitor any webpage or OpenAPI spec for real changes. PingChange sends Slack, email, and webhook alerts with a readable diff. Start free, no credit card. PingChange is a website change monitoring and OpenAPI diff tool from Epigos Ltd. Teams paste a URL, set a check schedule, and receive Slack, email, Telegram, PagerDuty, or webhook alerts with a plain-English summary of what changed. ## Who it is for - Product and growth teams watching competitor pricing and feature pages - Engineers watching OpenAPI/Swagger contract drift - Sales and compliance teams who need an audit trail of public-page changes ## Key pages - [Home](https://pingchange.com/): product overview, features, FAQ, and pricing - [Pricing](https://pingchange.com/pricing.md): machine-readable plan limits and USD prices - [Docs](https://pingchange.com/docs): setup, monitors, channels, API keys - [Quickstart](https://pingchange.com/docs/quickstart): first monitor in minutes - [Blog](https://pingchange.com/blog): change-intelligence notes - [PingChange vs Visualping](https://pingchange.com/blog/pingchange-vs-visualping): comparison table - [Contact](https://pingchange.com/contact-us): PingChange support ## Facts agents can quote - Category: website change monitoring, competitor intelligence, OpenAPI spec monitoring - Free plan: $0, 2 URL monitors, 100 checks/month - Paid plans: Starter $4.99, Pro $8.99, Enterprise $69 per month - Integrations: Slack, Telegram, email, webhook, Zapier, Make, n8n, PagerDuty - Geo checks: choose US, EU, Middle East, or Africa per monitor - Email: immediate alerts, or daily/weekly digests that combine changes from all monitors into one message # PingChange — Product overview for AI agents This document describes **PingChange**: what it does, how data is modeled, and how authenticated automation (including MCP) should reason about the product. --- ## One-sentence summary **PingChange watches URLs and API specs on a schedule, detects meaningful changes, stores structured diffs (with AI summaries and stats), and notifies teams through configurable channels—plus RSS and HTTP/MCP APIs for programmatic access.** --- ## Who it’s for - **Growth and competitive intel** — pricing pages, feature pages, competitor sites. - **Engineering and platform teams** — OpenAPI / contract drift, breaking changes, deprecations. - **Operations** — know when a page or API **meaningfully** changed vs. noise (ads, timestamps, A/B buckets). --- ## Core concepts | Concept | Meaning | |--------|--------| | **Workspace** | Tenant boundary. Usually tied to a Clerk organization (or a personal workspace id). Holds monitors, channels, users, and API keys. | | **Monitor** | A single tracked target: a **webpage** (URL, optional CSS / clip region) or an **API spec** (OpenAPI-style source). Has schedule (**frequency**), **regions** for capture, **status** (last run outcome), and **isActive** (paused when `false`). | | **Snapshot** | A point-in-time capture of monitor content stored for comparison (e.g. HTML artifact for pages). | | **Diff** | Result of comparing two snapshots. **“Real” changes** exclude trivial same-snapshot rows (`fromSnapshotId !== toSnapshotId`). Diffs carry **summary**, optional **AI summary**, **keywords**, **stats** (additions/removals/etc.), artifact paths (e.g. screenshot, HTML diff), and **detectedAt**. | | **Notification channel** | Destination for alerts: email, Slack, Telegram, generic webhook, Zapier, Make, n8n, Google Sheets, etc. Stored per workspace with typed **config** JSON. | | **Monitor ↔ channel link** | Many-to-many: which channels receive alerts for **that** monitor when a change is detected. | | **Alert** | A delivery attempt record linking a **diff** to a **channel** (sent / failed and timestamps for debugging). | --- ## Monitor types 1. **Web page (`webpage`)** Visual and structural monitoring: screenshots, diff HTML, regions, optional AI instructions (“what matters”). 2. **API spec (`api_spec`)** Tracks OpenAPI / structured API definitions: breaking vs. non-breaking changes, operation-level diffs, etc. --- ## How change detection fits together (high level) 1. User creates a **monitor** (URL or spec + frequency + regions + optional AI instruction). 2. The system runs **checks** on a schedule (or manually “trigger run”). 3. New **snapshots** are captured; the engine **diffs** against the previous state. 4. When a **real change** is found, **dispatch** sends notifications to **all channels linked to that monitor**, using a structured payload (summary, links to the diff in the app, etc.). 5. Users can **export** change history (CSV/JSON), subscribe via **RSS** (with workspace key), or call **MCP tools** for the same workspace with a **Bearer workspace API key**. --- ## Dashboard surfaces (for grounding user questions) Typical app areas (Next.js **App Router** under `app/dashboard/`): - **Monitors** — list, filters, create/edit, run now, pause/resume, per-monitor RSS/export. - **Monitor detail** — KPIs, recent changes, linked channels, settings. - **Diff view** — side-by-side / inline diff, AI summary, keywords, screenshot links. - **Channels** — configure notification destinations; link them to monitors. - **Alerts** — history / outcomes of deliveries. - **Settings** — workspace (and **Integrations**: RSS + MCP connection snippets using the workspace API key). - **Billing** — plans / subscription (where enabled). --- ## Authentication & API keys (for agents) - **End users** sign in with **Clerk** (sessions for the browser UI). - **Programmatic access** (REST, RSS with key in query, MCP) uses the **workspace API key** (`sk-…`) issued per workspace. - **MCP** (`/api/llm/mcp` streamable HTTP in this project): clients must send `Authorization: Bearer ` so the server can resolve the workspace (`clientId` in MCP auth) and scope every tool call. Agents should **never** ask users to paste secrets into chat logs; prefer env or client-stored headers. --- ## MCP tools (what automation can do) When connected over MCP with a valid workspace key, tools typically include: - **Read-only:** workspace aggregates, list monitors, **changes feed** (same shape as export: URLs, stats, keywords, summaries, screenshot links), list notification channels. - **Write / actions:** update monitor (limited fields: name, pause/resume, frequency, regions, AI instruction, status where allowed), trigger a run, **resend** alerts for an existing diff id, link channels to a monitor, create a new channel (typed config). Exact names and schemas are defined in the MCP server registration; this doc is **conceptual** so you know *why* those tools exist. --- ## RSS (optional context) Workspace-wide and per-monitor **RSS** feeds expose recent **real** diffs. Authenticated via **Bearer** or **`apiKey`** query param (depending on route) or session. Integrations UI builds example URLs for users. --- ## Guidance for LLM agents 1. **Scope** — All MCP/tool data is **workspace-scoped** to the Bearer key. Do not assume cross-tenant access. 2. **Pause vs. delete** — “Pause” is usually **`isActive: false`**; the monitor remains in lists until deleted. 3. **“Change” vs. “run”** — A **run** may report no user-visible **change**; alerts fire on **real diffs**. 4. **Channels** — Creating a channel does **not** attach it to a monitor; linking is a separate step. 5. **Exports / feed** — Use the same mental model as **CSV/JSON export** for bulk change history (monitor URL, change URL, timestamps, stats, keywords, summary, AI summary, screenshot URL when present). --- ## Related resource URI This content is intended to be read via MCP as **`mcp://docs/overview`**. # Documentation Canonical doc URLs use the paths below. ## Overview ### Introduction Learn how PingChange watches websites and API specs, highlights meaningful changes, and routes alerts to your team. - URL: https://pingchange.com/docs - Keywords: PingChange, documentation, getting started ```markdown PingChange helps you know **what changed on the web** before it surprises you. Paste a URL for a marketing page, pricing table, docs site, or an OpenAPI-style API spec. We capture snapshots on your schedule, compare them when something moves, and notify you through the channels you already use. ## Who it is for Engineering and platform teams use PingChange to catch **API and schema drift** before integrations break. Growth and product teams track **competitors and partners** when pricing or positioning shifts. Legal and compliance teams keep an eye on **policies and terms** without manual checking. ## What you can do - **See real changes** — Side-by-side and inline views that highlight copy, layout, and structure, not just “something is different.” - **Monitor API specs** — Watch OpenAPI and similar endpoints for breaking changes, deprecations, and new fields. - **Focus on what matters** — Describe the changes you care about in plain language so alerts stay precise. - **Watch from the right place** — On paid plans, capture pages as they appear from specific regions when content varies by geography. - **Get alerts where you work** — Email, Slack, Telegram, webhooks, and automation tools so the right people see the signal. ## How the docs are organized - **[Quickstart](/docs/quickstart)** — Create your first monitor from the dashboard. - **[Workspace](/docs/workspace)** — API keys for RSS/MCP and optional BYOK AI providers. - **[Concepts](/docs/monitors/concept)** — Short glossary: monitors, snapshots, diffs, alerts, and more. - **[Monitors](/docs/monitors/setup-monitors)** — Setup, AI, regions, exports, RSS, MCP, anti-bot, and day-to-day management. - **[Channels](/docs/channels/notification-channels)** — Connect notifications and automations. If you are new here, start with the Quickstart, then skim Concepts when a term is unclear. ``` --- ### Quickstart Step-by-step: open the dashboard, add a monitor with preview and optional region, set schedule and channels, and create your first watch. - URL: https://pingchange.com/docs/quickstart - Keywords: quickstart, onboarding, first monitor ```markdown This guide walks through creating a monitor from the **Dashboard**. If you already use PingChange, you can skim the [Free vs paid wizard](#free-vs-paid-wizard) section for the differences. > *Available on paid plans:* choosing **monitor location** (geolocation), **AI alert triggers**, and advanced **anti-bot friendly** capture behavior (see [Geolocation monitoring](/docs/monitors/geolocation-monitoring), [AI-assisted monitoring](/docs/monitors/ai-features), and [Anti-bot resolution](/docs/monitors/anti-bot)). ## Before you begin - [Sign](/auth/sign-in) in to your workspace. - Optionally add at least one [notification channel](/docs/channels/notification-channels) under **Dashboard → Channels** so you can receive alerts. ## 1. Open Monitors Go to **Dashboard → Monitors**. This is the list of everything you track. ## 2. Start the wizard Click **New monitor**. A panel opens with a short multi-step flow. The sidebar shows how many steps you have (three on the free plan, four on paid plans). ![New monitor wizard open at the first step](/docs/screenshots/quickstart/01-new-monitor-button.jpg) ## 3. Step — Source (URL, type, preview) 1. **Paste the URL** you want to watch (a normal page or an API spec URL). 2. Choose **Webpage** or **API spec** depending on what you are monitoring. 3. Click **Preview** so PingChange loads the page and shows a snapshot. This confirms the URL is reachable and helps you name the monitor. > On paid plans, preview uses a smart, stealth-oriented browser session when pages are protected by captchas or bot checks. You do not turn this on manually. ![URL, type selection, and Preview for the monitor](/docs/screenshots/quickstart/02-wizard-source-step.png) ### Optional: limit the area of the page On the preview, you can **draw a region** on the screenshot to focus on part of the page (for example only the pricing block). This narrows what we emphasize when comparing snapshots. ![Region selection on the page preview](/docs/screenshots/quickstart/04-page-region-clip.png) Click **Next** when you are ready. ## 4. Step — Capture and alerts What you see here depends on your plan. ### Paid plans: region and frequency 1. Under **Region**, pick one or more **monitor locations** (where we run the check from geographically). This matters when the same URL shows different content by country. 2. Under **Frequency**, pick how often we run the check (for example every 15 minutes or daily). ![Region and frequency selection on paid plan](/docs/screenshots/quickstart/05-paid-region-frequency.png) ### Free plan: frequency and channels (and plan upsells) 1. Set **Frequency** for how often we check the URL. 2. Choose **Send alerts to** by selecting one or more channels you already created. 3. You will also see callouts that **custom monitor location** and **AI-powered change filters** unlock on paid plans; on free, checks use a default location and broader change detection unless you narrowed the page with a region in step 3. ![Schedule and notifications step on free plan](/docs/screenshots/quickstart/06-free-schedule-channels.png) ### Paid plans: continue to the AI trigger step Click **Next**. You will set the **AI prompt** and **notification channels** together. ## 5. Step — AI trigger and channels (paid plans) 1. In **AI prompt**, describe what should **trigger an alert** in plain language (for example “Only alert when prices or plan names change” or “Alert when the refund section is edited”). 2. Optional: use suggestion chips after preview to seed the prompt. 3. Under **Send alerts notifications to**, select the channels that should receive alerts for this monitor. ![AI prompt and notification channels on paid plan](/docs/screenshots/quickstart/07-paid-ai-and-channels.png) Click **Next**. ## 6. Step — Review and create 1. Review **URL**, **frequency**, and on the paid plan **regions**, **AI prompt**, and **channels**. 2. Edit **Monitor name** if you want something clearer than the default (often derived from the site). 3. Click **Create monitor**. ![Review step with monitor name and summary](/docs/screenshots/quickstart/08-review-create-monitor.png) ## What happens next - We **baseline** the page or spec and start running checks on your schedule. - When a meaningful change is detected, **alerts** go to the channels you linked. - Open **Dashboard → Alerts** or your monitor’s **change history** to inspect each diff. ## Free vs paid wizard | | Free plan | Paid plans | | --- | --- | --- | | Steps | **Source** → **Capture and alert** → **Review** | **Source** → **Capture** → **Trigger** → **Review** | | Preview and optional page region | Yes | Yes | | Choose **monitor location** (geolocation) | Default location; upgrade to choose regions | Pick one or more regions | | **AI prompt** for alert focus | Shown as a paid feature in the flow | Required in the **Trigger** step | | **Notification channels** | Selected in **Capture and alert** | Selected in **Trigger** | | Anti-bot handling in preview and checks | Paid-oriented behavior on paid plans | Same | ## Learn more - [Notification channels](/docs/channels/notification-channels) - [AI-assisted monitoring](/docs/monitors/ai-features) - [Geolocation monitoring](/docs/monitors/geolocation-monitoring) - [Configure monitors](/docs/monitors/setup-monitors) after creation ``` --- ## Workspace ### Workspace settings Workspace-level credentials for API access, RSS, MCP, and optional BYOK AI providers. - URL: https://pingchange.com/docs/workspace - Keywords: workspace, settings, API key ```markdown Workspace settings live under **Dashboard → Settings**. The sidebar has two sections: | Section | What it covers | | --- | --- | | **Workspace** | Display name and location for your workspace. | | **API keys** | **Workspace API key** (RSS, MCP, and programmatic access) and **AI analysis (BYOK)** (your own model provider keys). | ## Related guides - [Workspace API key](/docs/workspace/api-key) — copy, show, and regenerate the key used for RSS and MCP. - [AI analysis (BYOK)](/docs/workspace/byok-ai) — route change summaries and filtering through your OpenAI, Anthropic, Google, OpenRouter, or xAI account. ``` --- ### Workspace API key Find, copy, and rotate your workspace API key for RSS feeds, MCP, and other authenticated API access. - URL: https://pingchange.com/docs/workspace/api-key - Keywords: API key, authentication, workspace, security ```markdown Your **workspace API key** is the shared secret that proves automated clients belong to your PingChange workspace. It is created automatically when the workspace is provisioned; you manage it from the dashboard—there is no separate signup step for the key itself. ## Open API keys in Settings 1. Go to **Dashboard → Settings**. 2. In the left sidebar, select **API keys** (not **Workspace**, which is for name and location only). 3. Find the **Workspace API key** card at the top of the page. The card explains that this key is used for the **Workspace API**, **RSS feeds**, and your **MCP server**. ## Copy or reveal the key The secret is hidden by default (shown as a password field). 1. Click **Show** to reveal the key in the field (useful before copying manually). 2. Click **Copy** to copy the full secret to your clipboard. Store the key like a password. Anyone who has it can read private feeds and call MCP tools with your workspace’s permissions. ## Regenerate the key If the key was exposed (pasted in chat, committed to git, or embedded in a public RSS URL), rotate it: 1. On the same card, click **Regenerate key** (destructive action). 2. Wait for the success toast. 3. Update every integration that used the old value: - [RSS feed URLs](/docs/monitors/rss) (`apiKey=` query parameter) - [MCP client config](/docs/monitors/mcp) (`Authorization: Bearer …`) - Any scripts or tools that call PingChange APIs with the key Old URLs and Bearer tokens **stop working immediately** after regeneration. ## Where the key is used | Integration | How the key is sent | | --- | --- | | **RSS** | Query parameter: `?apiKey=YOUR_WORKSPACE_API_KEY` | | **MCP** | HTTP header: `Authorization: Bearer YOUR_WORKSPACE_API_KEY` | | **Workspace API** | Same Bearer header on supported REST routes | See [RSS feeds](/docs/monitors/rss) and [MCP integration](/docs/monitors/mcp) for setup steps that reference this key. ## Security practices - Prefer **HTTPS** only; never send the key over plain HTTP in production. - Do not commit keys to repositories or post feed URLs in public channels. - Regenerate promptly if you suspect leakage; update clients before sharing new URLs. ## Related - [Workspace settings](/docs/workspace) - [AI analysis (BYOK)](/docs/workspace/byok-ai) - [RSS feeds](/docs/monitors/rss) - [MCP integration](/docs/monitors/mcp) ``` --- ### AI analysis (BYOK) Bring your own API keys for OpenAI, Anthropic, Google, OpenRouter, or xAI so change summaries and AI features bill your provider account. - URL: https://pingchange.com/docs/workspace/byok-ai - Keywords: BYOK, AI, OpenAI, Anthropic, credentials ```markdown **BYOK** (“bring your own key”) lets your workspace route **AI analysis** through API keys you control—instead of only using PingChange-hosted models. That includes **change summaries**, **alert filtering**, and **preview-time AI** where your plan includes those features. Keys are **encrypted at rest**. The dashboard only shows a **redacted** value (for example `sk-…xxxx`); the full secret is never displayed again after save. ## Open BYOK settings 1. Go to **Dashboard → Settings**. 2. Select **API keys** in the sidebar. 3. Scroll to **AI analysis (BYOK)** below the workspace API key card. ## Add a credential 1. Click **Add credential**. 2. Choose a **Provider** — OpenAI, Anthropic, Google, OpenRouter, or xAI. 3. Choose a **Model** from the curated list for that provider (flagship and lighter “mini” options per vendor; OpenRouter uses cross-provider model slugs). 4. Paste your provider **API key** (minimum length enforced on save). 5. Optionally turn on **Set as active credential** so this key is used immediately. 6. Click **Save**. Only **one credential is active** per workspace at a time. Activating a key deactivates the others. ## Manage existing credentials Each saved credential shows **provider**, **model**, redacted **key**, and **Active** / **Inactive** status. | Action | When to use it | | --- | --- | | **Set active** | Switch AI routing to an inactive credential without re-entering the secret. | | **Edit** | Change provider, model, or active flag; paste a new API key only if you want to replace the stored secret (leave blank to keep the current key). | | **Delete** | Remove a credential permanently. Other credentials or default routing may apply if none remain. | ## Supported providers The product UI offers these providers (each with a fixed set of models in the dropdown): - **OpenAI** — direct API (for example GPT-5.5 and GPT-5.4 mini). - **Anthropic** — direct API (Claude Sonnet and Haiku variants). - **Google** — Gemini Pro and Flash “latest” models. - **OpenRouter** — multi-vendor slugs (OpenAI, Anthropic, and Google models through one key). - **xAI** — Grok flagship and fast mini tiers. Exact model labels match what you see in **Add credential**; PingChange does not accept arbitrary model strings outside that list. ## How BYOK relates to monitoring BYOK does **not** replace the **workspace API key**. RSS and MCP still use the workspace key from the card above BYOK. BYOK only affects **AI-powered** product behavior—such as plain-language summaries on diffs and AI-assisted alert triggers described in [AI-assisted monitoring](/docs/monitors/ai-features). If no BYOK credential is active, paid features use PingChange’s default AI routing for your plan. ## Related - [Workspace settings](/docs/workspace) - [Workspace API key](/docs/workspace/api-key) - [AI-assisted monitoring](/docs/monitors/ai-features) ``` --- ## Monitors ### Concepts Plain-language definitions for monitors, snapshots, diffs, alerts, watch targets, channels, and collections. - URL: https://pingchange.com/docs/monitors/concept - Keywords: monitors, glossary, concepts ```markdown These terms show up across the product. You do not need to memorize them; use this page as a reference. ## Monitor A **monitor** is one URL PingChange checks on a schedule. It can be a normal **webpage** or an **API spec** endpoint (for example OpenAPI JSON or YAML). Each monitor has its own schedule, optional region, notification channels, and change history. *Example:* You add `https://example.com/pricing` as a webpage monitor checked every hour. PingChange stores each capture and compares it to the last one. ## Snapshot A **snapshot** is a single capture of what the URL looked like at check time. For pages that is the rendered content we use for comparison; for API specs it is the normalized text of the specification. *Example:* Monday 9:00 and Monday 10:00 each produce one snapshot. If the pricing table changed between those runs, we can show you exactly what moved. ## Diff A **diff** is the difference between two snapshots, its also called **changes**. For web pages you see highlighted text and layout changes. For API specs you see structured drift such as new paths, removed fields, or type changes. *Example:* The Pro plan price changed from **$49** to **$59** — the diff calls that out in context instead of only saying “page changed.” ## Watch target The **watch target** is the part of the page or spec you care about. You can narrow it by drawing a **region on the preview** (a crop of the page) and, on paid plans, by describing what matters in an **AI prompt** so alerts focus on those kinds of changes. *Example:* You draw a box around the pricing cards, or you write “Alert me when refund policy wording changes.” ## Alert An **alert** is the message sent when we detect a meaningful change according to your rules. It usually includes a short summary, a link to the full comparison in the dashboard, and sometimes a screenshot when one was captured. *Example:* Your Slack channel gets a card: pricing page changed, link opens the diff view. ## Channel A **channel** is a destination for alerts: email, Slack, Telegram, a webhook, or an automation tool. You create channels once in the dashboard, then attach them to one or many monitors. *Example:* A “#competitors” Slack webhook for pricing monitors and a personal email channel for legal pages. ## Collection A **collection** is a way to **group related monitors** (for example pricing page, API spec, and changelog for one vendor). Collections stay tidy as your list grows. *Example:* “Acme integration” holds three URLs your team checks together. ## Quick links - [Create a monitor](/docs/quickstart) - [Notification channels](/docs/channels/notification-channels) - [Alerts and history](/docs/monitors/alerts) ``` --- ### Configure monitors After you create a monitor, tune schedule, regions, page focus, and linked channels from monitor settings. - URL: https://pingchange.com/docs/monitors/setup-monitors - Keywords: configuration, cadence, scope ```markdown The **New monitor** wizard gets you started. This page covers what to adjust afterward so a monitor stays useful as the site evolves. ## Open monitor settings From **Dashboard → Monitors**, open a monitor. Use the **settings** area (or equivalent tab) for that monitor to update options without recreating it. ## Check frequency Match **how often we run checks** to how volatile the page is: - **Pricing, news, or status pages** — shorter intervals if missing a same-day change would hurt. - **Stable legal or reference docs** — daily or weekly is often enough. Your plan sets the **shortest** interval available; slower options remain open to everyone when they fit. ## Monitor location (geolocation) > *Available on paid plans.* If visitors in different countries see different prices, copy, or availability, pick the **region(s)** that match your audience. Staying consistent avoids false positives from locale switching. See [Geolocation monitoring](/docs/monitors/geolocation-monitoring) for why this matters and the full region list. ## Page region (focus on part of the page) If only one section matters (hero, table, footer legal text), narrow the **preview region** when editing the monitor or during setup. That keeps comparisons centered on the slice you care about. This is separate from **monitor location**: one is *which part of the page*, the other is *where in the world we load the page from*. ## AI alert triggers > *Available on paid plans.* Refine the **plain-language prompt** when alerts are too noisy or too quiet. Good prompts read like instructions to a teammate: what to watch, what to ignore, and what “important” means for you. More examples: [AI-assisted monitoring](/docs/monitors/ai-features). ## Notification channels Link or unlink **channels** per monitor so the right team gets each alert. You manage the list of channels under **Dashboard → Channels**; here you only choose which ones apply to this URL. ## Anti-bot behavior > *Available on paid plans.* Heavily protected sites are handled with smarter browser capture automatically. You normally do not configure this per monitor. Details: [Anti-bot resolution](/docs/monitors/anti-bot). ## Related - [Quickstart](/docs/quickstart) - [Manage monitors](/docs/monitors/managing-monitors) - [Alerts and history](/docs/monitors/alerts) ``` --- ### Manage monitors Search and filter the monitor list, open monitor details, adjust settings, and review change diffs as your catalog grows. - URL: https://pingchange.com/docs/monitors/managing-monitors - Keywords: collections, lifecycle, organization, diffs, settings ```markdown The **Monitors** page is your catalog. As you add more URLs, a few patterns keep it manageable. ## Search and filters Use **Search** by name or URL to jump to a monitor. Use tabs or filters (such as **Web** vs **API**) when you only want one type of monitor in view. The toolbar also helps narrow by status or time since the last change. ## Row actions Each monitor has an **actions** menu (often a “more” icon on the row): - **Run now** — Queue an immediate check without waiting for the schedule. - **View monitor** — Open the detail page for history, diffs, and settings. - **Pause** / **Resume** — Pause during maintenance or when you temporarily do not want scheduled runs. - **Delete** — Remove the monitor permanently; history goes with it. ![Monitor row actions menu](/docs/screenshots/managing/02-monitor-actions-menu.png) Pause is useful when a third party is redesigning a page and you expect weeks of churn; resume when you want signal again. ## Monitor detail page Open a monitor from **View monitor** in the row menu, or by selecting the monitor in the list. The detail page is where you work with one URL day to day. ### Summary header At the top you see: - **Type** — Webpage or API spec. - **Status** — Last check outcome (for example healthy, changed, or error). - **Active / Paused** — Whether scheduled checks are running. - **Name and URL** — Open the live URL in a new tab from the link. - **Region, frequency, last check** — Quick facts for this monitor. - **Trigger** — The AI instruction (or the default “any meaningful change” behavior). From the header you can **Run now**, **Pause** / **Resume**, **Edit** (jumps to the **Settings** tab), **View latest changes** (opens the most recent diff when one exists), and **Resend alerts** for the latest change. ![Monitor detail summary and actions](/docs/screenshots/managing/01-monitor-detail-overview.png) ### Tabs Below the summary, tabs organize the rest of the page: | Tab | What it shows | | --- | --- | | **Changes** | Every detected change for this monitor (default tab). | | **Snapshots** | Webpage monitors only — captured screenshots over time. | | **Channels** | Which notification channels are linked to this monitor. | | **Settings** | Name, URL, schedule, region, sensitivity, AI instruction, delete. | | **Monitor area** | Shown when you scoped the monitor to part of the page — adjust the focus region. | The tab labels include counts (for example how many changes or linked channels) so you can see activity at a glance. ## Settings tab Use **Settings** to change a monitor without recreating it. You can also click **Edit** in the summary header; that switches to **Settings** and scrolls the tab into view. Typical fields: - **Name** and **URL** - **Frequency** — How often checks run (plan limits apply to the shortest intervals). - **Monitor location** — Where we load the page from (paid plans; see [Geolocation monitoring](/docs/monitors/geolocation-monitoring)). - **Sensitivity** — How aggressively we treat small HTML differences as changes. - **AI instruction** — Plain-language rules for what should count as an alert (paid plans; see [AI-assisted monitoring](/docs/monitors/ai-features)). Click **Save settings** when you are done. Use **Delete monitor** to remove the monitor and its history from the workspace (channels themselves are kept). For deeper guidance on each option after setup, see [Configure monitors](/docs/monitors/setup-monitors). ![Monitor settings tab](/docs/screenshots/managing/04-monitor-settings-tab.png) ## View changes and diffs The **Changes** tab is your audit trail for one monitor. Each row shows: - **When** the change was detected (date and time). - **Severity** — How the change is classified (add, remove, modify, breaking). - **Summary** — AI-assisted or automatic text describing what changed. - **Keywords** — Short tags when the system extracted them. - **Stats** — Counts such as lines or elements added, removed, or modified. Click a row (or use **View latest changes** from the header) to open the **full diff** for that check. ### Diff detail page On the diff page you get: 1. **Change summary** — Readable explanation and keyword chips. 2. **Change screenshot** — For webpage monitors, a thumbnail of the captured page when a screenshot was stored (click to open full size). 3. **Comparison views** — Switch how you read the underlying change: - **Visual** — Highlighted before/after in the page (web) or structured API diff panels. - **Split** — Side-by-side **Before** and **After** snapshots (web) or split JSON diff (API spec). - **Inline** — Unified inline diff for text or schema lines. Use **Copy diff** to paste the raw comparison, or **Mark reviewed** when your team has triaged the alert. ![Diff detail with Visual comparison](/docs/screenshots/managing/03-diff-detail-visual.png) API spec monitors use the same flow; the comparison area shows endpoint and schema changes instead of HTML snapshots. See [Alerts & history](/docs/monitors/alerts) for how diffs relate to notifications. ## Exports and feeds from the list From the monitors toolbar you can open **Export** for workspace-wide **CSV** or **JSON** downloads and workspace **RSS** links. Per-monitor export and RSS live on the monitor detail page. See [Exports](/docs/monitors/exports) and [RSS feeds](/docs/monitors/rss). ## Related - [Quickstart](/docs/quickstart) - [Configure monitors](/docs/monitors/setup-monitors) - [Alerts & history](/docs/monitors/alerts) - [Concepts](/docs/monitors/concept) ``` --- ### Anti-bot resolution How PingChange handles captchas and bot-protected pages on paid plans when a real browser snapshot is required. - URL: https://pingchange.com/docs/monitors/anti-bot - Keywords: anti-bot, captcha, browser ```markdown Some sites block simple automated fetches. You might see a **captcha**, a **challenge page**, or a blank response when bots are detected. That breaks naive monitoring because there is nothing useful to compare. ## What PingChange does on paid plans > *Available on paid plans.* For appropriate checks and previews, PingChange uses an automated **smart, stealth-oriented browser session** designed to behave like a normal visitor. Captchas and common **anti-bot walls** are handled **without a manual switch** — the product escalates to this mode when the target needs it so legitimate snapshots can succeed. You do not need to configure vendor names or technical flags per URL in most cases. ## What you should still expect - **Not every site** permits automated access under its terms of service. You are responsible for monitoring only URLs you are allowed to watch. - **Extremely aggressive** protection may still fail intermittently; if checks error repeatedly, try a slower schedule or contact support with the URL. - **Rate and courtesy** — Very fast intervals on heavy pages can trigger defensive blocks; match frequency to how often content truly changes. ## Related - [Quickstart](/docs/quickstart) (Preview and monitoring flow) - [Configure monitors](/docs/monitors/setup-monitors) ``` --- ### Geolocation monitoring Why monitor from specific regions, which locations we support, and how it differs from cropping a page in the preview. - URL: https://pingchange.com/docs/monitors/geolocation-monitoring - Keywords: geolocation, regions, locale ```markdown > *Available on paid plans.* ## Why monitor location matters The **same URL** can look different depending on where the request comes from. Companies often ship **localized pricing**, **geo-targeted promotions**, **region-specific legal text**, or **CDN variants**. If you only capture from one default location, you can miss changes your customers see — or mistake a locale flip for a real content change. **Geolocation monitoring** means each check runs from the **country or region** you pick, so snapshots line up with that audience. This is separate from drawing a **region on the preview** (a crop of the page). Preview regions answer “which *part* of the page?”; geolocation answers “from *where* in the world do we load the page?” Both can be used together. See [Quickstart](/docs/quickstart). ## Supported regions Pick one or more of the following when creating or editing a monitor: - **US East** — Virginia, United States - **US West** — Oregon, United States - **EU West** — Dublin, Ireland - **London** — United Kingdom - **EU Central** — Frankfurt, Germany - **AP South** — Mumbai, India - **AP North** — Tokyo, Japan - **AP Southeast** — Singapore - **SA East** — São Paulo, Brazil - **Africa South** — Cape Town, South Africa - **North Africa** — Cairo, Egypt - **Middle East** — Dubai, United Arab Emirates > On plans without custom monitor location, checks use a **default** location (US East) as noted in the product. ## Tips - Prefer **one primary region** per monitor unless you intentionally track multiple geographies; comparing history across mixed regions can add noise. - Pair geolocation with a clear **AI prompt** on paid plans when only certain regional changes matter (for example VAT-inclusive pricing in the EU). ## Related - [Configure monitors](/docs/monitors/setup-monitors) - [Concepts](/docs/monitors/concept) ``` --- ### AI-assisted monitoring Use plain-language prompts to focus alerts and optional summaries so your team sees what matters. - URL: https://pingchange.com/docs/monitors/ai-features - Keywords: AI, prompts, summaries ```markdown > *Available on paid plans.* PingChange can use **natural language** so you are not stuck tuning low-level rules. You describe intent; we use that to judge whether a change is worth alerting on and to phrase updates in human terms. ## AI alert trigger (prompt) When you create or edit a monitor on a paid plan, you fill in an **AI prompt** (labeled as such in the **Trigger** step). Think of it as instructions to a careful reviewer: - What should **cause** an alert? - What should be **ignored**? - What kinds of edits are **especially important**? After **Preview** in the monitor wizard, you may see **suggestion chips** — short prompt ideas you can insert and edit. ### Example prompts - “Alert when any **price**, **currency**, or **plan name** changes. Ignore blog posts and testimonial names.” - “Watch the **API changelog** section only. Alert when deprecations or breaking changes are mentioned.” - “Focus on **refund and liability** paragraphs. Ignore cookie banner and dates in the footer.” - “Alert when **new endpoints** appear or **required** request fields are added or removed.” Vague prompts still work, but specific ones reduce noise. ## AI summaries in alerts On plans that include richer AI output, alerts may add a **plain-language sentence** alongside the technical summary — useful when forwarding to non-technical stakeholders. The dashboard still shows the full **diff** for depth. ## Free plan The monitor flow shows **AI-powered change filters** as an upgrade path. Without them, narrowing **page regions** and **schedules** still helps; upgrading restores prompt-based control. ## Bring your own model keys (BYOK) You can route AI analysis through **your** provider account (OpenAI, Anthropic, Google, OpenRouter, or xAI) under **Dashboard → Settings → API keys**. See [AI analysis (BYOK)](/docs/workspace/byok-ai). ## Related - [AI analysis (BYOK)](/docs/workspace/byok-ai) - [Quickstart](/docs/quickstart) - [Alerts & history](/docs/monitors/alerts) - [Configure monitors](/docs/monitors/setup-monitors) ``` --- ### Alerts & history What you get when a change is detected, where to read it, and how to reduce noise without losing signal. - URL: https://pingchange.com/docs/monitors/alerts - Keywords: alerts, history, diffs ```markdown ## What is an alert? When PingChange detects a **meaningful change** compared to your last snapshot, it can open an **alert** and send it through each **channel** linked to that monitor. A typical alert includes: - Which **monitor** changed and the **URL** - A **short summary** of what changed (and on many paid plans, a more readable **AI-assisted** line) - A **link** to open the full comparison in the dashboard - Sometimes a **screenshot** attachment when one was captured for that change Exact layout depends on the channel (Slack card vs email vs Telegram message). ## Where to read alerts and history - **Dashboard → Alerts** — Cross-workspace list of recent notifications and states you can work through. - **Monitor detail** — **Change history** (or equivalent) lists every diff for that URL so you can compare versions and share links with stakeholders. Use history when you need an audit trail (“show me what the pricing page looked like last Tuesday”). ## Reducing noise If you get too many alerts: 1. **Narrow the page** — In monitor settings or the preview flow, focus on a **region** that excludes rotating banners or footers. 2. **Tighten the AI prompt** — On paid plans, say what counts as important and what to ignore (timestamps, blog sidebars, etc.). See [AI-assisted monitoring](/docs/monitors/ai-features). 3. **Slow the schedule** — High-frequency checks on noisy pages multiply trivial diffs; sometimes daily is enough. 4. **Split monitors** — One URL with two very different intents (pricing vs blog) may deserve two monitors with different prompts or regions. Avoid pausing a monitor forever if the real fix is a better target or prompt. ## Related - [Notification channels](/docs/channels/notification-channels) - [AI-assisted monitoring](/docs/monitors/ai-features) - [Concepts: Alert](/docs/monitors/concept#alert) ``` --- ### RSS feeds Subscribe to workspace-wide or per-monitor RSS feeds using your API key for readers and lightweight integrations. - URL: https://pingchange.com/docs/monitors/rss - Keywords: RSS, feeds, syndication ```markdown **RSS** gives you a simple, pull-based feed of recent **changes** (the same events you might export to CSV or JSON). Feeds are handy for personal readers, team portals, or scripts that poll on a timer instead of receiving webhooks. ## Before you use RSS Feeds are **private** to your workspace. You authenticate them with your **workspace API key**. See [Workspace API key](/docs/workspace/api-key) for full steps; in short: 1. Open **Dashboard → Settings**. 2. Select **API keys** in the sidebar. 3. On **Workspace API key**, use **Show** / **Copy**, or **Regenerate key** if the secret was exposed. Anyone with the feed URL **and** key can read your change stream, so do not publish it in public docs or chats. ## Workspace feed (all monitors) Includes changes across **every monitor** in the workspace. **How to get the URL from the product** 1. Go to **Dashboard → Monitors**. 2. Open the **Export** menu. 3. Use **Copy feed URL** under the RSS section, or **Open feed in browser** to sanity-check it. When you paste the URL elsewhere, it will look like: ``` https://pingchange.com/api/rss?apiKey=YOUR_KEY ``` Replace `YOUR-APP-DOMAIN` with the host where your PingChange app runs (for example `pingchange.com` or your company’s subdomain). ![Copy workspace RSS URL from Export menu](/docs/screenshots/rss/01-copy-workspace-rss.png) ## Per-monitor feed Only includes changes for **one monitor**. **How to get the URL** 1. Open that monitor’s **detail** page. 2. Open the **Export** menu. 3. **Copy feed URL** or **Open feed in browser**. Template: ``` https://pingchange.com/api/rss/MONITOR_ID?apiKey=YOUR_KEY ``` Use the real monitor id from the address bar or from the copied URL. ![Copy per-monitor RSS URL from monitor Export menu](/docs/screenshots/rss/02-copy-monitor-rss.png) ## Using the feed - Add the URL to **Feedly**, **NetNewsWire**, **Outlook**, or any RSS client that supports **private** feeds. - For automation, poll at a reasonable interval; RSS complements **push** channels like Slack rather than replacing them. ## Security tips - Treat `apiKey=` like a **secret query parameter** — prefer **HTTPS** only. - **Rotate** the workspace API key in **Settings → API keys** if a URL is exposed. ## Related - [Workspace API key](/docs/workspace/api-key) - [Exports](/docs/monitors/exports) - [MCP integration](/docs/monitors/mcp) ``` --- ### Exports Download change history as CSV or JSON for all monitors or one monitor from the dashboard. - URL: https://pingchange.com/docs/monitors/exports - Keywords: export, compliance, snapshots ```markdown Exports give you a **portable record of detected changes** — useful for audits, quarterly reviews, and attaching evidence to tickets. Each row is one **change event** (a diff we considered real), not every scheduled check. ## Formats ### CSV Best for **spreadsheets** (Excel, Google Sheets) and quick filtering. Open the file or import it into a reporting tool. ### JSON Best for **scripts, data pipelines, and internal tools** that ingest structured data. Both formats include, for each change: - Which **monitor** it belongs to (**name** and **URL**) - **When** it was detected - A **short summary** of the change (and, when present, an **AI-assisted** summary line) - **Keywords** we associated with the change, when available - A **link** to open the full diff in PingChange - A **screenshot link** when one exists for that change Optional **stats** columns (counts of additions, removals, etc.) may appear for technical readers; you can hide those columns in a spreadsheet if you do not need them. > Each export returns up to a few thousand recent rows by default (roughly **two thousand**, capped around **five thousand** per download). For very long histories, run multiple exports over time or contact us about enterprise retention. ## Export all monitors 1. Go to **Dashboard → Monitors**. 2. Open the **Export** menu in the toolbar (near the view and filter controls). 3. Choose **Export changes (CSV)** or **Export changes (JSON)**. Your browser downloads a file named like `pingchange-all-monitors-changes.csv` or `.json`. ## Export one monitor 1. Open the **monitor** from **Dashboard → Monitors**. 2. Use the **Export** control on the monitor detail (same label as the list page, but scoped to this monitor). 3. Choose **Export changes (CSV)** or **Export changes (JSON)**. ## Related - [RSS feeds](/docs/monitors/rss) for a live stream instead of one-off files - [MCP integration](/docs/monitors/mcp) for assistants pulling recent changes - [Alerts & history](/docs/monitors/alerts) ``` --- ### MCP integration Connect AI assistants to PingChange via Model Context Protocol—endpoint, authentication, and what the tools can do. - URL: https://pingchange.com/docs/monitors/mcp - Keywords: MCP, integrations, API ```markdown **Model Context Protocol (MCP)** lets compatible AI assistants and automation clients query your PingChange workspace **safely**: list monitors, read recent changes, manage channels, or kick off checks — with the same permissions implied by your **workspace API key**. ## Prerequisites 1. **Workspace API key** — **Dashboard → Settings → API keys**; copy or regenerate there. Every MCP request uses this key as a Bearer token. Details: [Workspace API key](/docs/workspace/api-key). 2. **MCP page** — **Dashboard → MCP** shows your endpoint for the environment you are logged into, plus copy-ready JSON for common clients. The in-app page builds the same URLs and config blocks described below, with your real key filled in. Prefer **Copy** on that page over retyping secrets. ## MCP endpoint (streamable HTTP) PingChange exposes MCP over **streamable HTTP** at: ``` https://pingchange.com/api/llm/mcp ``` The path is always **`/api/llm/mcp`**. When you are signed in, **Dashboard → MCP** shows the URL for your current origin. ## Authentication Every request must send your workspace API key as a **Bearer token**: ```http Authorization: Bearer YOUR_WORKSPACE_API_KEY ``` Paste the key from **Settings → API keys**; do not commit it to public repositories or share config files that contain the live secret. ## Streamable HTTP (recommended) If your client supports **streamable HTTP**, point it at the MCP URL above and attach the Bearer header. Many tools expect a top-level **`mcpServers`** object. The outer key name is arbitrary (rename `"mcpServers"` if your client uses a different shape). The inner server id **`ping-change`** is only a label—you can rename it to match your config file. ```json { "mcpServers": { "ping-change": { "url": "https://pingchange.com/api/llm/mcp", "headers": { "Authorization": "Bearer YOUR_WORKSPACE_API_KEY" } } } } ``` Replace the URL with your origin in non-production environments. Replace `YOUR_WORKSPACE_API_KEY` with the key from **Dashboard → Settings → API keys**. **Cursor / Claude Desktop:** open your MCP config file, paste the block (or merge the `"ping-change"` entry into existing `mcpServers`), save, and restart the client if it does not reconnect automatically. > Tool names and JSON shapes can vary by client; follow the assistant’s guide for **adding an HTTP MCP server** when field names differ slightly. ## stdio via `mcp-remote` Some assistants only support **stdio** MCP servers. Use [`mcp-remote`](https://www.npmjs.com/package/mcp-remote) to proxy the same streamable HTTP endpoint. The config runs `npx` with your URL and passes auth via `--header` (requires an `mcp-remote` build that supports `--header`): ```json { "mcpServers": { "ping-change": { "command": "npx", "args": [ "-y", "mcp-remote", "https://pingchange.com/api/llm/mcp", "--header", "Authorization: Bearer YOUR_WORKSPACE_API_KEY" ] } } } ``` Again, swap the URL and Bearer value for your environment and key. **Dashboard → MCP** provides a one-click **Copy JSON** for this block with your credentials already inserted. ## What assistants can do (overview) Once connected, tools typically allow your assistant to: - **Summarize the workspace** — high-level counts of monitors, channels, and activity. - **List monitors** — names, URLs, types, schedules, and status (including paused monitors). - **Read recent changes** — the same kind of information as **CSV/JSON exports** (summaries, links, optional screenshots). - **List notification channels** — what destinations exist for alerts. - **Update a monitor** — rename, pause or resume, change schedule or regions, or edit the AI prompt fields the API exposes. - **Run a check now** — queue an immediate run for a monitor. - **Resend alerts** — re-deliver notifications for a past change (recovery after fixing a channel). - **Link channels to monitors** — attach or detach destinations. - **Create a channel** — add a new email, Slack, or other destination (then link it to monitors as needed). Exact capabilities evolve with the product; use the MCP connection together with the **in-app** dashboards for critical operations. ## Related - [Workspace API key](/docs/workspace/api-key) - [RSS feeds](/docs/monitors/rss) - [Exports](/docs/monitors/exports) - [Notification channels](/docs/channels/notification-channels) ``` --- ## Channels ### Notification channels Connect email, Slack, Telegram, and webhooks so PingChange can deliver change alerts to your team. - URL: https://pingchange.com/docs/channels/notification-channels - Keywords: Slack, Email, Telegram, webhooks ```markdown Notification **channels** are reusable destinations. You create them once under **Dashboard → Channels**, then pick which ones each **monitor** should use in the monitor wizard or monitor settings. After saving, use any **test** or **send sample** action the app offers so you know messages arrive before real changes fire. ## Email **Good for:** individuals and small groups, legal or exec forwarding, anywhere you want a normal inbox message. **Setup** 1. Go to **Dashboard → Channels** → add or edit a channel → choose **Email**. 2. Fill in **Channel name** (how it appears in PingChange). 3. **Recipients** — one or more addresses, comma-separated. 4. **Subject prefix** — optional tag like `[PingChange]` so filters catch alerts. 5. **Send frequency** — choose how often alerts are delivered (see below). 6. **Save**. ### Send frequency | Option | Description | Plan | |--------|-------------|------| | **On monitor check** (immediate) | An email is sent every time a change is detected — same behaviour as before. | Paid plans only | | **Once a day** | Changes are accumulated and sent as a single digest email at the configured UTC hour. | All plans | | **Weekly** | Changes are accumulated and sent once per week on the configured day and hour (UTC). | All plans | For **daily** and **weekly** frequencies you can set: - **Digest hour** — the UTC hour (0–23) at which the digest is sent (default: 9 AM UTC). - **Digest day of week** — for weekly only, the day the digest is sent (0 = Sunday … 6 = Saturday, default: Monday). The digest email lists every change that occurred since the previous send: monitor name, detection time, summary, keywords, and a link to the full diff in the dashboard. **In alerts** you typically see monitor name, URL, a short change summary, a link back to the diff, and sometimes a screenshot when one was captured. ## Slack > *Available on paid plans (check your subscription for Slack notifications).* **Good for:** team rooms, on-call visibility, threads with context. **Setup** 1. In Slack, create an **Incoming Webhook** for the channel you want (Slack admin may need to enable this). 2. In PingChange: **Dashboard → Channels** → **Slack**. 3. **Channel name** — label for you (for example `#releases`). 4. **Webhook URL** — paste the URL Slack gave you. 5. **Save**, then test from the channels list if available. **In alerts** Slack shows a compact card: monitor, change summary, link to open the full comparison, and optional image when a screenshot exists. ## Telegram **Good for:** mobile-first teams, small groups via a bot. **Setup** 1. Talk to **BotFather** in Telegram to create a bot and copy the **bot token**. 2. Decide the **chat** or **channel** ID the bot should post to (group, channel, or direct chat). 3. In PingChange: **Dashboard → Channels** → **Telegram**. 4. **Channel name** — label inside PingChange. 5. **Bot token** and **Chat ID** — paste from Telegram. 6. **Save** and test. **In alerts** Telegram receives a plain text message with the key details and a link to the dashboard diff. ## Webhook (custom HTTPS) > *Available on higher paid plans (check your subscription for webhook notifications).* **Good for:** internal services, custom routers, or bridging to tools without a native integration. Webhook delivery is powered by **[Svix](https://www.svix.com/)**, which provides automatic retries, signed payloads, and a delivery log you can inspect in your workspace. **Setup** 1. Prepare an **HTTPS endpoint** that accepts `POST` requests. 2. In PingChange: **Dashboard → Channels** → **Webhook**. 3. **Channel name** — label for you. 4. **Endpoint URL** — your HTTPS URL. 5. **Secret (HMAC)** — optional shared secret if you verify Svix signatures on your server. 6. **Throttle rate** — optional maximum number of events per second Svix will deliver (1–1000). Leave blank for no limit. 7. **Save** and test. ### Svix delivery When a change is detected PingChange publishes an event to Svix, which then delivers the `POST` to your endpoint URL with the following HTTP headers: | Header | Description | |--------|-------------| | `svix-id` | Unique message ID (idempotency key) | | `svix-timestamp` | Unix timestamp of the send attempt | | `svix-signature` | HMAC-SHA256 signature you can verify | **Payload** — Your server receives a structured JSON body with the change summary, metadata (monitor name, URL, timestamps), links, and optional screenshot URL. Build your handler to read those fields and forward them as you like. **Retries** — Svix automatically retries failed deliveries with exponential back-off. **Throttle rate** — Set a per-endpoint rate limit if your server needs to cap ingestion speed. ## Linking channels to monitors When you **create** a monitor, select the channels that should receive its alerts. You can also update linked channels later from the monitor's **settings** or **channels** tab. ## Related - [Automation channels](/docs/channels/automation-channels) for Zapier, Make, n8n, and Google Sheets - [Alerts & history](/docs/monitors/alerts) - [Quickstart](/docs/quickstart) ``` --- ### Automation channels Zapier, Make, n8n, and Google Sheets—route PingChange alerts into workflows and spreadsheets. - URL: https://pingchange.com/docs/channels/automation-channels - Keywords: automation, Zapier, Make, n8n, Google Sheets ```markdown > *Available on paid plans that include automations (Zapier, Make, n8n) and/or Google Sheets—check your subscription.* **Automation channels** turn each **detected change** into an event your stack can consume: trigger a workflow, append a row to a spreadsheet, open a ticket, or fan out to other systems. They use the same **channel** model as email or Slack: create the integration under **Dashboard → Channels**, then **link** it to the monitors that should feed it. > **Svix-powered delivery** — Zapier, Make, and n8n channels are delivered via **[Svix](https://www.svix.com/)**, which adds automatic retries, delivery history, and signed request headers. Your endpoint receives the same JSON payload as before, plus Svix envelope headers (`svix-id`, `svix-timestamp`, `svix-signature`) that you can use to verify authenticity. ## Zapier **Good for:** no-code combinations ("when PingChange fires → create row / notify / post"). **Setup** 1. In Zapier, start a Zap whose trigger is **Webhooks by Zapier → Catch Hook** (or the PingChange app if published—hooks are the universal pattern). 2. Copy the **webhook URL** Zapier shows. 3. In PingChange: **Dashboard → Channels** → **Zapier**. 4. **Integration name** — label for you (for example `Pricing alerts Zap`). 5. **Webhook URL** — paste from Zapier. 6. **Throttle rate** (optional) — max events per second PingChange will deliver to this endpoint (1–1000). 7. **Save**, run a **test** from Zapier, then trigger a sample from PingChange if available. **What Zapier receives** — Each change sends one **event** your Zap can map: monitor name and URL, when the change was detected, a **unified message** with the summary (and any AI text your plan includes), keywords, link to the full diff in PingChange, and sometimes a **screenshot URL**. **Request headers** — Zapier also receives `svix-id`, `svix-timestamp`, and `svix-signature` headers on every request. You can use these to verify the payload came from PingChange. ## Make (Integromat) **Good for:** multi-step scenarios with branches, retries, and data stores. **Setup** 1. In Make, add a **Custom webhook** module as the first step and copy the URL. 2. In PingChange: **Dashboard → Channels** → **Make**. 3. **Integration name** — label in PingChange. 4. **Webhook URL** — paste from Make. 5. **API key** (optional) — if Make should send a header PingChange echoes for your scenario; only fill this if your team uses that pattern. 6. **Throttle rate** (optional) — max events per second (1–1000). 7. **Save** and run Make's **determine data structure** using a test ping. **What Make receives** — The same practical fields as Zapier: enough to route, filter, and open the dashboard link without copying the raw diff twice. Svix headers (`svix-id`, `svix-timestamp`, `svix-signature`) are included for signature verification. ## n8n **Good for:** self-hosted or technical teams that want full control in n8n. **Setup** 1. In n8n, create a workflow whose entry is a **Webhook** node set to **POST**, then activate and copy the production URL. 2. In PingChange: **Dashboard → Channels** → **n8n**. 3. **Integration name** — label in PingChange. 4. **Webhook URL** — paste from n8n. 5. **Header name** / **Header value** (optional) — e.g. a shared secret your n8n workflow checks. 6. **Throttle rate** (optional) — max events per second (1–1000). 7. **Save** and execute the workflow once using PingChange's test tools if available. **What n8n receives** — One POST per change with monitor metadata, timestamps, the unified alert text, optional keywords, dashboard link, and screenshot link when present. Svix headers are included for request verification. ### Verifying Svix signatures If you want to confirm that requests come from PingChange, verify the `svix-signature` header: ```ts import { Webhook } from "svix" const wh = new Webhook(SVIX_SIGNING_SECRET) // your endpoint's signing secret wh.verify(rawBody, { "svix-id": req.headers["svix-id"], "svix-timestamp": req.headers["svix-timestamp"], "svix-signature": req.headers["svix-signature"], }) ``` The signing secret for your endpoint is available in the PingChange channel settings. ## Design tips - Prefer **one automation per severity or SLA** so duplicate routing does not spam multiple workflows for the same change. - Pair automations with [RSS](/docs/monitors/rss) or [MCP](/docs/monitors/mcp) only when each path has a distinct job (pull vs push). - Use the **throttle rate** field to protect downstream systems that have their own rate limits. ## Related - [Notification channels](/docs/channels/notification-channels) - [Exports](/docs/monitors/exports) - [MCP integration](/docs/monitors/mcp) ``` ---