Two new x402 APIs for AI agents: OpenAPI breaking-change diff + rate-limit policy inference

Why these two?

After shipping 82 paid x402 endpoints over the last two months, I keep hitting the same two questions during integration: "did this API just break my code?" and "how fast can I safely hit this?" Existing tools answer these manually — open-source oasdiff, swagger-diff, and openapi-compare need installation, YAML config, and 30s+ spin-up. Rate-limit detection requires reading RFC 9239 draft and vendor-specific quirks.

So I shipped two endpoints that do the work in one HTTP call for $0.0005 each.

/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.

What it reports:

• 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).

How to call

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:

1. 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.
2. 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.