Zillow API caching: what fresh property data means

A new request can return an earlier collection

PropertiesAPI caches repeated property lookups for 24 hours under its documented lookup policy. A request made now can therefore return data collected earlier. Use the response’s collection timestamp and cache metadata to describe freshness accurately.

This is useful for repeat views of the same property, but it changes what “current” means in your application. A page rendered today is not necessarily a property record collected today, and a successful response does not guarantee the source has not changed since collection.

Store three different times

Keep request time, collection time and export or display time separate. They answer different questions. Combining them into one updated_at column makes troubleshooting and user-facing labels ambiguous.

Read cache and source metadata

For the property endpoint, inspect x-cache and meta.cached. Retain meta.fetched_at or the documented collection timestamp alongside the property. Do not replace it with the local system clock when writing the row to a database.

If your application adds its own cache, keep its timestamp separately as well. You can otherwise create two layers of caching while showing users only the time the outer layer was refreshed. That gives a misleading impression of source freshness.

Choose a freshness rule for the actual decision

A saved research view and a user checking whether a rental is still available have different needs. Set a product rule describing when a snapshot is too old for the intended decision, and show the collection date prominently.

Repeatedly requesting the same property during the cache window does not force a new collection. Do not invent an undocumented cache-bypass parameter or imply that a browser refresh guarantees a live source read. If your workflow requires a different freshness guarantee, establish support for it before promising it to customers.

Deduplicate repeat work without hiding identity changes

Use a confirmed returned property ID when grouping repeated lookups. Retain the original input mapping so you can still audit which address or URL led to each record. Avoid deduplicating distinct units by street address alone.

If a later collection returns a different identity or an explicit warning, do not overwrite the old property silently. Place the update into review. Cache efficiency is useful only when the cached object belongs to the home the user requested.

Separate cache accounting from success accounting

A cached successful result is still a successful property lookup for application purposes, but its credit treatment differs from a successful live collection. Read response metadata and reconcile with account usage rather than counting HTTP 200 responses as billed credits.

An operational summary should show cache hits, fresh successes and failures separately. That helps explain changes in usage without claiming that the cache provides a specific speed improvement. Measure latency in your own workload if it matters to the application.

Present an honest freshness label

A practical label is “Collected on [date and time]” with a cache indicator where useful. Avoid “live now” on every result. If the data is older than your workflow accepts, show that state and offer an appropriate next step.

Test cached and uncached fixtures, missing timestamps and a stale local copy. Verify that exports preserve the source collection time. These small checks prevent a common integration error: turning a timestamp for data movement into a claim about when the property itself was observed.