100,000 Units · billed annually
One maintained market for a first production workflow.
Request access →CleanedWeb pricing
Choose the coverage, freshness, history and delivery capacity your workflow needs. Crawls and retries never become line items, while unchanged records cost one-tenth of a first delivery.
100,000 Units · billed annually
One maintained market for a first production workflow.
Request access →500,000 Units · billed annually
Five markets with faster updates and change delivery.
Request access →2,000,000 Units · billed annually
All standard markets, full history and bulk delivery.
Request access →Volume, coverage and service levels
A dedicated property-data contract around your workflow.
Contact us →CleanedWeb Units
One canonical record can combine several source listings. You pay for the data object delivered—not the collection work behind it.
One merged listing, once per billing month.
The same merged listing delivered again without a new observed change.
One observed price, status, source or availability change.
One previous observed listing state returned from history.
Full details or available agent information.
Full comparison
Scroll horizontally on smaller screens to keep every plan side by side.
| Feature | Starter $99 | Growth $399 | Scale $1,000 | Enterprise Custom |
|---|---|---|---|---|
| Usage and coverage | ||||
| Monthly Units | 100,000 | 500,000 | 2,000,000 | Custom |
| Property markets | 1 selected | 5 selected | All standard | Custom |
| Additional 1,000 Units | $1.00 | $1.00 | $0.50 | Volume pricing |
| Merged listing first delivery | 1 Unit | 1 Unit | 1 Unit | Contracted |
| Unchanged listing delivery | 0.1 Unit | 0.1 Unit | 0.1 Unit | Contracted |
| Listing change event | 0.25 Unit | 0.25 Unit | 0.25 Unit | Contracted |
| Historical listing state | +0.25 Unit | +0.25 Unit | +0.25 Unit | Contracted |
| Maintained data | ||||
| Refresh schedule | Daily | Up to 6 hours | Priority, hourly target | Contracted |
| Observed listing history | 90 days | 12 months | Full available | Custom and backfills |
| Cross-source deduplication | ✓ | ✓ | ✓ | ✓ |
| Merged canonical records | ✓ | ✓ | ✓ | ✓ |
| Source provenance | ✓ | ✓ | Field level | Custom controls |
| Persistent listing identity | Standard | Cross-source | Cross-market | Custom rules |
| Price, status and availability events | ✓ | ✓ | ✓ | ✓ |
| Match confidence metadata | — | Standard | Detailed | Custom |
| Search and delivery | ||||
| Advanced database filters | ✓ | ✓ | ✓ | ✓ |
| REST API and JSON delivery | ✓ | ✓ | ✓ | ✓ |
| CSV export | ✓ | ✓ | ✓ | ✓ |
| Historical and changed-since filters | Basic | Full | Full | Custom |
| Saved searches | — | ✓ | ✓ | ✓ |
| Scheduled exports | — | ✓ | ✓ | Custom |
| Change webhooks | — | ✓ | High volume + replay | Custom streams |
| Incremental synchronization API | — | ✓ | ✓ | Custom |
| Historical bulk export | — | — | ✓ | Custom |
| Cloud or warehouse delivery | — | — | Cloud storage | Custom destination |
| Workspace and support | ||||
| Team seats | 2 | 5 | 10 | Custom |
| API keys | 2 | 5 | 20 | Custom |
| Support | Priority email | Priority | Named contact | |
| Technical onboarding | Documentation | Integration review | Guided | Dedicated |
| Usage and team controls | Account | Team | Advanced | Custom roles |
| Service-level agreement | — | — | — | ✓ |
| Enterprise controls | ||||
| Dedicated acquisition and query capacity | — | — | — | ✓ |
| Customer-prioritized source development | — | — | — | ✓ |
| Custom schemas and identity rules | — | — | — | ✓ |
| SSO, audit logs and role-based access | — | — | — | ✓ |
| Retention and deletion controls | Standard | Standard | Advanced | Contracted |
| Licensing and redistribution review | — | — | — | ✓ |
| Choose your plan | Starter | Growth | Scale | Contact us |
Questions that matter
The commercial model is simple. The infrastructure underneath it is not. These are the boundaries a technical, financial or enterprise buyer should inspect.
A crawler produces a response. We maintain property state. Source-specific acquisition runs underneath the product, but it is not the customer contract. We collect listings, normalize them into a versioned schema, resolve matching records, preserve provenance and record subsequent changes. Customers query that maintained layer without operating an integration for every portal. The acquisition system can evolve while the data contract remains stable.
Five portals can publish five descriptions of the same opportunity. We treat each description as a source assertion, then resolve identity using the strongest available evidence: source identifiers, canonical URLs, location, property attributes and other stable signals. A conservative match produces one canonical listing with persistent identity and preserved source links. Ambiguous records remain separate. Deduplication should reduce noise without manufacturing certainty.
Source dependence does not disappear. It moves out of the customer application and into our acquisition plane. We absorb layout changes, pagination drift, access failures and source replacements behind one data contract. Source health, freshness timestamps and partial-delivery semantics make degradation visible instead of silently corrupting the result. One portal can fail without forcing every downstream product to rediscover the failure independently.
Merging is not voting, and a database is not automatically truth. We retain the source, collection time and identifiers behind each assertion. Resolution can consider recency, completeness, source-specific confidence and deterministic field rules. Higher plans expose deeper match and field-level provenance. The result is one usable record with an audit trail, not one opaque answer that hides the disagreement.
Freshness is a measured property, not an adjective. Every market has its own source mix, update frequency and access constraints. Plan cadence defines the target collection window; record timestamps expose when a listing was first seen, last seen and last changed. Enterprise agreements can contract source-specific freshness objectives. We do not collapse all markets into a universal “real-time” claim.
A portal page is a moment. A maintained listing is a time series. We record observed price, status, availability, source, removal and reactivation events as coverage permits. History begins when we start tracking a listing or when a named market backfill begins. It does not automatically include deeds, ownership, title or completed transactions. Historical depth is explicit by market because false completeness is worse than a clearly bounded dataset.
Property markets are rich in information asymmetry but poor in normalized time-series infrastructure. A research desk, credit platform or real-asset product does not need another page scrape. It needs a stable universe, persistent identity and observable deltas: new supply, repricing, withdrawals, relistings, inventory turnover and cross-market dispersion. The listing is not the signal. The change is. We provide queryable inputs and lineage; customers own signal construction, validation and investment decisions.
Provenance is part of the record, not a support ticket. Source URLs, external identifiers, collection timestamps and first-seen or last-seen state establish how a listing entered the system. Historical events preserve when the state changed. Scale and Enterprise can expose deeper match confidence and field-level lineage. That audit path matters for model governance, research reproducibility, exception handling and any decision that must be defended later.
Database reads are not the product. Maintained data objects are. The first delivery of a canonical listing in a billing month costs one Unit, even when several sources contributed to it. Delivering that unchanged listing again costs 0.1 Unit. New change events, historical states and explicit enrichments have their own visible Unit cost. Internal crawls, retries, browsers and source complexity never become surprise line items.
Start with snapshots through REST, JSON or CSV. Move to saved searches, change webhooks and incremental synchronization when the workflow becomes continuous. Scale adds historical bulk and cloud delivery; Enterprise can target a contracted warehouse or private destination. Stable identifiers support idempotent upserts, while change events let downstream systems process the delta instead of reloading the entire universe.
Partial data must identify itself. We distinguish current observations, last-known state and unavailable sources so a downstream system can choose whether to proceed, defer or exclude a market. Freshness timestamps show the age of the evidence. Enterprise service levels can define escalation and recovery expectations for contracted coverage. A successful response should never imply that every source was healthy when it was not.
API access is not a blanket redistribution license. Normalized facts, source media, retention, attribution, bulk export and customer-facing redistribution are separate control surfaces. Enterprise agreements can review the intended product, markets, delivery path and relevant source constraints before defining permitted use. We keep provenance and media boundaries visible so commercial access does not erase the rights attached to the underlying material.
Enterprise is a data contract, not a larger credit bundle. It can define market and source coverage, freshness objectives, dedicated acquisition and query capacity, historical backfills, retention, schemas, identity rules, delivery destinations, access controls, audit logs and incident response. The agreement turns the coverage envelope and operating expectations into explicit commitments around one real workflow.
History boundary
History begins when CleanedWeb starts tracking a listing or when a named market backfill begins. It does not imply complete deed, transaction or ownership history. Available depth and refresh frequency can vary by market and source.
CleanedWeb API
We will review the market, expected volume and delivery path with you.
Request access →