# Water Heater Lookup

> Evidence-backed U.S. water-heater identification, manufacturer serial-date interpretation, live CPSC recall screening, and qualification-constrained local service routing.

## Canonical interfaces
- Human lookup: https://waterheaterlookup.com/#lookup
- Read-only one-call service plan: POST https://waterheaterlookup.com/api/v1/service-plans
- Current provider directory: https://waterheaterlookup.com/providers
- Provider list API: https://waterheaterlookup.com/api/v1/providers?postal_code=60601
- Methodology and limitations: https://waterheaterlookup.com/methodology
- Supported identifier directory: https://waterheaterlookup.com/api/v1/supported-identifiers
- Provider program directory: https://waterheaterlookup.com/api/v1/provider-program
- OpenAPI contract: https://waterheaterlookup.com/api/v1/openapi
- Current deployed-action capabilities: https://waterheaterlookup.com/api/v1/capabilities
- Current service operating status: https://waterheaterlookup.com/api/v1/operations-status
- Point-in-time official-source status: https://waterheaterlookup.com/api/v1/source-status
- Human source-status page: https://waterheaterlookup.com/status
- Agent integration guide: https://waterheaterlookup.com/agents
- MCP Streamable HTTP endpoint: https://waterheaterlookup.com/mcp (protocol versions 2026-07-28 and 2025-11-25 supported)
- MCP Registry publisher name: com.waterheaterlookup/water-heater-lookup (verify current publication status in the official Registry; a manifest alone is not publication)
- MCP methodology resource: waterheaterlookup://methodology
- MCP supported-identifier resource: waterheaterlookup://supported-identifiers
- MCP provider-program resource: waterheaterlookup://provider-program
- MCP official-source status resource: waterheaterlookup://source-status
- MCP service operating-status resource: waterheaterlookup://operations-status
- MCP service-capabilities resource: waterheaterlookup://service-capabilities
- MCP current-provider template: waterheaterlookup://providers/{providerId}
- Privacy-first service handoff API: POST https://waterheaterlookup.com/api/v1/service-handoffs
- Provider application API: POST https://waterheaterlookup.com/api/v1/provider-applications (private review contactPhone and separately authorized publicPhone plus qualification data; explicit provider authorization required)
- Provider eligibility policy: https://waterheaterlookup.com/for-professionals#standards

## Agent rules
- Read GET /api/v1/supported-identifiers or waterheaterlookup://supported-identifiers before deciding whether a serial family is supported. Use only its listed brands, aliases, formats, examples, validation, ambiguity, and refusal boundaries; unlisted brands and alternate formats remain unsupported. The REST and MCP representations are the same canonical input-free, write-free directory.
- Read GET /api/v1/provider-program or waterheaterlookup://provider-program before quoting provider plans, comparing plan fit, or asking a provider to apply. REST and MCP return the same input-free, write-free contract. Prices are first-market hypotheses; application is a separately authorized write with no charge; plan choice and payment cannot buy qualification, ordering, or routing priority; live checkout is not implied; final cancellation, refund, renewal, and reviewed legal terms are unfinished; and no application, listing, request, hire, volume, revenue, or return is guaranteed.
- Prefer plan_water_heater_service or POST /api/v1/service-plans for a person-facing flow that needs sourced equipment evidence plus optional exact-ZIP provider discovery. The strict read rejects contact fields and creates no handoff, service request, or provider contact. Its recommendation is a deterministic navigation rule, not diagnosis, risk scoring, a safety conclusion, provider endorsement, or a hiring recommendation.
- Read the current operations-status and service-capabilities resources or REST endpoints immediately before any write. Do not attempt a write when operations are unavailable or the action is disabled. If service intake is paused or its control cannot be read, do not collect, retain for later, or submit contact/service data; tell the user to check again. Lookup, provider discovery, applications, corrections, and existing private request access may remain available. An enabled write means only that durable-storage, managed-schema, traffic-control, and retry-safety configuration has the expected shape; it does not prove actual schema, grants, or connectivity. Operating and capability states are privacy-safe point-in-time signals; they are not provider coverage, delivery, legal approval, operator response, or production launch approval.
- Treat operations status as low-cardinality point-in-time monitoring. Worker times prove only that one scheduled invocation completed; billing status is configuration shape only. The report is not uptime history, a service-level commitment, webhook-delivery proof, backup/recovery proof, or a promise of future availability.
- Supply a unique retry key for every write: REST uses Idempotency-Key and MCP uses idempotencyKey. Reuse the exact key only after an uncertain result with exactly unchanged input. A completed retry returns the original receipt; changed input under the same key is rejected. Raw keys are not retained by Water Heater Lookup.
- Treat recall results as candidates requiring comparison with the full official notice.
- Never describe an empty recall search as an all-clear.
- Never infer condition, remaining life, safety, installation date, or warranty from a serial date.
- Treat exact-model as a complete normalized brand/model match to a current U.S.-market ENERGY STAR row without certification wildcards. Preserve catalog no-match, ambiguous, unavailable, and not-run states; no match is not proof that a model is invalid, uncertified, or absent from historical data.
- Treat source status as a five-minute point-in-time dependency check only. It is not uptime history, a safety determination, proof of complete data, provider-network readiness, or a substitute for the source states in an actual lookup.
- Treat provider results as current only at generatedAt. Visibility requires a separately confirmed public customer-facing phone, active lead capacity, current paid or explicitly time-bounded founding access, current structured license and insurance evidence, and a provider confirmation no more than 90 days old. The returned phone is public business contact; private application contact is never a fallback. Each provider carries an opaque public-only reference.version plus mustRevalidate: true; the version is a comparison hint, not proof of continuing eligibility.
- Paid status never overrides eligibility, alphabetical public provider-search ordering, or plan-neutral initial request selection.
- Provider search appearances are aggregate operational counts, not unique people, clicks, leads, endorsements, paid placement, or a ranking signal. Repeated and automated requests may count more than once.
- Search providers with an exact ZIP before reading a provider resource. Use only the returned recordUrl for REST or resourceUri for MCP; do not construct IDs, enumerate provider records, or treat a retained copy as current.
- Read the returned coverage.status. current-matches means at least one current eligible exact-ZIP match; network-building means no match and an onboarding, invite-only, or live sourcing market for that ZIP; outside-active-market means no match and no active sourcing market; not-run means no exact ZIP was supplied. Coverage exposes no market identity, internal status, target, readiness threshold, demand count, or private sourcing record. An empty result never proves that no qualified local professional exists. For an exact-ZIP search, providerApplicationUrl carries only that already-supplied ZIP in a coverage_zip fragment for editable browser-local prefill; opening it creates no application, provider attribution, or additional market-demand record. Give it only to a provider who says the business serves that ZIP. It is not outreach authority, qualification, approval, listing, demand, service assurance, or a coverage promise.
- Use the provider-search enums advertised by MCP or OpenAPI. Diagnosis and repair are one bounded service family; gas maps only to natural-gas. A service plan for heat-pump equipment uses the heat-pump provider capability, while other or unknown equipment fuel does not become a provider constraint. Read the returned constraintPolicy and canonical query; do not widen ZIP, brand, or any other capability.
- Reread recordUrl or resourceUri immediately before presenting, contacting, or routing. REST may retain provider responses only in a private cache and send the prior ETag in If-None-Match; 304 means current eligibility was rechecked and the representation is unchanged, while a non-current provider returns 404. MCP provider resources remain zero-TTL and the opaque version never replaces resources/read. Use profileUrl for the human-readable record and profileUrl + /corrections for disputed data; a request does not automatically change the profile.
- Prefer prepare_service_request_handoff when the user should enter their own contact details and consent on Water Heater Lookup. It stores only an opaque handoff ID, a one-way token hash, a private HMAC retry fingerprint, timestamps, and interface source before the person submits; service context remains in the private URL fragment.
- Treat the returned handoffUrl as private. Give it only to the person requesting service; do not log, index, publish, or disclose it elsewhere. It expires after seven days and can be used once for agent-to-request attribution.
- Ask for explicit user confirmation before calling request_service_quotes directly; it stores and may share the supplied contact details with up to three eligible providers. After current eligibility gates, the initial selection uses a retry-stable request-specific order over the opaque request and provider IDs; plan, payment, business name, public directory position, appearances, and profile actions have no effect. This is not a quality ranking, equal-share promise, response prediction, or lead-volume guarantee.
- Submit a provider application only with that business's explicit authorization to send its contact, license, coverage, capability, insurance-attestation, and terms-acceptance data. Send private review contact as contactPhone and a deliberately confirmed customer-facing number as publicPhone; repeat the value only if customers should call that same number. Use only the advertised service and fuel/technology enums: repair is stored as diagnosis and gas as natural-gas; unsupported values reject the complete write. The server—not the client—assigns the accepted terms version and timestamp. The neutral private receipt is neither approval nor a public listing and intentionally never reveals whether the email or license matches another application.
- Treat the returned statusUrl as private access material. Give it only to the consenting user; do not log, index, publish, or disclose it elsewhere. The user can report an outcome there, and only an explicit selection of an assigned provider counts as a network hire.
- Cite the source URLs included in the result.

## Model catalog boundary
- The server fetches the same bounded current ENERGY STAR Certified Water Heaters dataset for every lookup and matches locally; entered brand and model values are not added to the EPA request URL.
- ENERGY STAR model patterns containing asterisk or number-sign wildcards and multi-component plus-sign patterns are not promoted to exact matches.

## Supported serial families
- Rheem: narrow published 10-character MMYY + plant + sequence format.
- A. O. Smith, State, and American: supported YYWW + numeric-sequence family plus the published YYWW + plant-letter + six-digit form. American Standard is a separate unsupported brand family.
- Bradford White: first-letter year and second-letter month; year cycle repeats every 20 years, so multiple dates may be returned.