Real estate license API coverage

A jurisdiction is marked live only after RELD has an ingestion path, normalized licensee records, status handling, and repeatable refresh checks in place. The public count is not a market-size estimate; it reflects rows loaded from regulator source data and reviewed for the API shape used by customers.

Coverage depth varies by source. Some regulators publish broker, salesperson, brokerage, branch, and affiliation data together. Others publish licensee records without every relationship field. RELD keeps the source-specific details available while presenting common fields consistently, so teams can build one integration and still understand what each regulator actually provides.

The roadmap is separate from production coverage. Roadmap states have been identified for future support, but they are not returned by production search or verification endpoints until ingestion is implemented and validated. If a state is critical to your rollout, the contact link helps us prioritize real deployment needs over speculative backlog order.

Refresh cadence is also part of the coverage decision. RELD does not treat every source as a nightly source when the regulator itself publishes slower files or when portal behavior makes a different schedule more reliable. The goal is to give customers a trustworthy freshness signal, not a blanket promise that hides source constraints.

For live jurisdictions, downstream systems should rely on the API response metadata rather than a hard-coded marketing page value. The public table is useful for evaluation and planning, while the coverage endpoint is the operational source for integration logic, monitoring, and customer-facing availability messages.

This distinction matters for compliance workflows. A team can use this page to decide whether RELD is likely to support a market, then use the API to log the exact record, source status, and verification timestamp used in an internal decision. That keeps the marketing view readable while preserving a more precise audit trail in the product itself.

When a regulator changes its portal, file format, or published fields, RELD reviews the ingestion path before updating public expectations. That is why coverage language on this page is intentionally conservative: it separates what is live, what is planned, and what depends on source data that may differ from state to state.

The practical result is a coverage page that helps buyers plan, and an API coverage endpoint that helps software make decisions.