x402 新增 OpenAPI 变更检测与限频推断 API

在过去的两个月里上线了 82 个付费 x402 端点后，集成时我反复遇到两个同样的问题："这个 API 是不是刚刚破坏了旧代码？"以及"我最快能以什么速度安全地调用它？"现有工具都只能手动回答——开源的 oasdiff、swagger-diff 和 openapi-compare 需要安装、配置 YAML，还要等待 30 秒以上的启动时间。速率限制检测则需要研读 RFC 9239 草案和各种厂商特定的行为差异。

所以我上线了两个端点，一次 HTTP 调用就能完成这些工作，每次仅需 $0.0005。

/api/openapi-diff — breaking-change detector

Input: two OpenAPI 3.x or Swagger 2.0 specs (URL or inline). Accepts JSON or YAML, auto-detects format.

breaking_count — changes that will break old clients (removed paths, removed operations, type changes, enum narrowing, added required request fields)

additive_count — safe changes (added operations, removed required fields, new response fields)

info_count — non-functional (summary/description edits)

modified_operations[] with per-field diffs

is_compatible — bool, true if breaking_count == 0

diff_score 0-100 A-F grade (100 = identical)

Verified with Petstore v3.0.4 (self-compare): 13 paths, 19 operations, 0 breaking, score 100/A, is_compatible=True.

Verified breaking detection: narrow status enum ["available","pending","sold"] to ["available"] to 1 breaking flagged (enum_narrowed: status removed ['pending', 'sold']), score 90/A, is_compatible=False.

Pricing: $0.0005 per call via x402 (USDC on Base, payTo 0xCa0a...).

/api/rate-limit-policy — policy inference + burst probe

Input: a URL + optional burst parameter (default 8, max 30).

How it works: combines static header analysis with an adaptive burst probe.

Headers it recognizes: RFC 9239 RateLimit-Limit/Remaining/Reset/Policy, X-RateLimit-* (GitHub/Twitter legacy), X-Rate-Limit-, Retry-After, X-Quota-, vendor-specific (X-Anthropic-RateLimit-*-Tokens, X-Shopify-Shop-Api-Call-Limit).

Burst probe: fires N requests (no delay) and measures the 429 ratio + Retry-After pattern.

Policy classification:

• explicit_rfc9239 — server returns RateLimit-Policy header
• fixed_window — reset is a hard timestamp
• sliding_window — Retry-After decays over the burst
• leaky_bucket — uniform Retry-After
• token_bucket — remaining refills between bursts
• none_detected — no signal at all
• unknown — headers present but unclassifiable

Returns: limit, remaining, reset_seconds, reset_at_iso (epoch to ISO conversion), burst_results[], max_safe_burst (recommended concurrent requests), burst_429_count, burst_detected, rate_limit_score 0-100 A-F grade.

Verified with api.github.com burst=3: 5 headers detected, policy fixed_window, limit=60, remaining=59, reset_seconds=1790781045 to 2026-09-30T15:10:45Z, max_safe_burst=59, score 75/B.

Verified with example.com burst=2: 0 headers, policy none_detected, score 0/F (correct: no rate limiting on example.com).

Both endpoints are GET, take URL params, return JSON, gated by x402 at $0.0005. Use the standard x402 flow:

curl -H "X-PAYMENT: <base64_payment_payload>" \
  "https://lighter-munich-requirement-partially.trycloudflare.com/api/openapi-diff?url_a=<URL_A>&url_b=<URL_B>"

Full catalog: GET /.well-known/x402 (85 endpoints). Specs: GET /openapi.json.

Why these matter for agents

Two real failure modes:

Agent consumes an API, the API ships a breaking change, agent silently misparses or 500s. openapi-diff can be wired into a CI/pre-deploy step.

Agent scrapes or polls a site without knowing the rate limit, gets 429-banned. rate-limit-policy returns max_safe_burst directly so the agent can pace itself.

Both shipped together: 85 paid endpoints, all $0.0005, all USDC on Base, all served through Cloudflare quick-tunnel.