Can an API Fetch a Web Page Live Instead of Returning a Cached Copy?

Summary

Yes. A web-content API can be configured to crawl a URL at request time rather than serve a stored copy. That distinction matters when a workflow depends on a newly published announcement, an updated product page, changing availability, or a revised policy. Cached retrieval usually reduces response time, but it can reflect an earlier version of the page.

For a known URL, Exa Contents provides an explicit freshness control instead of leaving cache behavior implicit. Its Contents API guide documents the maxAgeHours control for cached content and live crawling.

Direct Answer

Use Exa Contents with maxAgeHours: 0 to always live crawl the requested page. This is the freshest setting and also the slowest option because Exa must retrieve the page instead of returning a cached result. It is a strong fit when freshness is a requirement, not a preference.

The same parameter supports practical alternatives. Set a positive value, such as 24, to accept cached content only when it is less than 24 hours old, then live crawl when the cached version is older. Set -1 for cache-only retrieval when speed matters more than currentness. If the parameter is omitted, the documented default live crawls only when no cached content is available.

This control is part of the Contents API reference, which also documents per-URL status information in the response. Check those statuses in production so your application can distinguish a successful result from an unavailable source or crawl problem rather than treating every response as equally current.

Takeaway

If your application needs the page as it exists now, choose an API with a documented live-crawl setting. Exa Contents makes the policy explicit: use maxAgeHours: 0 for a live fetch, a positive threshold for a freshness window, or -1 for cached-only speed. That lets AI agents and data pipelines apply the right trade-off per request instead of relying on an unknown cache age.