API Change Watch
EN中文
Menu
Get alerts
Public preview · Automatic monitoring and email alerts are not enabled

Build snapshot for UTC 2026-09-03, not live metrics. JavaScript recalculates date states for the current UTC day; sources are not reverified.

Updates, actions and deadlines are separate decisions

New models and capabilities are product updates, not urgent migrations. Deprecations, shutdowns and changes affecting existing calls remain action notices even without dates. Only explicit migration/removal deadlines enter the deadline queue. Severity is recorded separately.

official_documentation means official docs support availability or lifecycle status, without necessarily stating an announcement date. Month-only sources retain their locator and null date; never invent the first day of a month.

Source registry and regional limits →
Home/Methodology

Trust model

Detection is a signal. Verification is a decision.

We separate mechanical page changes from provider announcements so teams can act on evidence without confusing a changed document with a confirmed lifecycle event.

MVP boundary: the current site uses a small, manually verified seed dataset. No production crawler, scheduler, database, email sender or AI classifier is running.

1. Sources we monitor

Only public, login-free primary sources are eligible for verified events:

  • Official API documentation and deprecation pages
  • Official product or developer change logs
  • Official migration guides and lifecycle tables
  • Official GitHub Releases from a provider-owned repository

Community posts, news coverage and social posts may help discovery but cannot verify a record. We do not bypass authentication, CAPTCHA, robots directives, rate limits, access controls or IP blocks.

2. Two different records

RecordMeaningPublish rule
official_announcementThe provider explicitly states a change, date, replacement or lifecycle status in a primary source.May be marked verified after a human-readable evidence check.
detected_diffA watched public page changed between two stored snapshots.Remains detected or needs_review until the changed text supports a normalized event.

3. Verification states

  • Verified: the normalized claim, provider, affected surface and dates are supported by the linked primary source.
  • Needs review: evidence exists but timing, scope or replacement is ambiguous.
  • Detected: a mechanical difference was found; it is not yet an announcement.

4. Severity rules

SeverityRule of thumb
CriticalA dated shutdown or removal that can make production requests fail, or a migration deadline inside 30 days.
HighA breaking request/response behavior, enforced replacement, pricing change with material unit impact, or a dated shutdown inside 90 days.
MediumA model alias migration, longer-range deprecation or behavior change that needs planned validation.
LowLong-range lifecycle information or a low-impact operational change that should remain on the roadmap.

Severity describes operational urgency, not model quality or provider reliability. A provider changing a date triggers re-verification and may change severity.

5. Deadline calculation

Countdowns use the published calendar date and UTC day boundaries. When a provider says “earliest,” “tentative,” or “not sooner than,” the event retains that qualification in its summary. Missing dates remain missing; they are never inferred.

6. Future automated pipeline

  1. Cloudflare Cron triggers a bounded list of public source fetches.
  2. A Worker stores response metadata and content hashes in D1.
  3. Deterministic comparison creates a detected_diff candidate.
  4. Grok Bot may classify the diff and draft a summary, but cannot approve facts.
  5. A verification step promotes supported candidates to verified.
  6. Workers enqueue eligible subscriptions; Resend, webhook and Slack adapters deliver alerts.

Mechanical scheduling, fetching, storage and delivery remain deterministic infrastructure responsibilities. AI is limited to classification and summarization.