Data and Cache Functions

This page is the quick-lookup version of Next.js's data-caching APIs. For the full explanation of how the Data Cache, Full Route Cache, and Client Router Cache interact, see the Caching chapter.

Reading With Caching Options

fetch(url, { next: { revalidate } }) Extends the native fetch() with a Next.js-specific next.revalidate option (in seconds): caches the response in the Data Cache and automatically re-fetches it in the background after that many seconds have elapsed. Set to false to cache indefinitely, or 0 to opt out of caching.
fetch(url, { next: { tags } }) Tags a cached fetch response with one or more string labels so it can later be invalidated on demand with revalidateTag(), without waiting for its time-based revalidation window.


Invalidating On Demand

Both functions below live in next/cache and are only callable from Server Actions and Route Handlers -- they have no effect if called from a plain Server Component render.

revalidatePath(path, type?) Purges the Data Cache and Full Route Cache for a specific path (or, with type: 'layout', every path sharing that layout) the next time it's visited, letting you push fresh data out immediately after a mutation instead of waiting for time-based revalidation.
revalidateTag(tag) Purges every cached fetch() entry (across any route) that was tagged with the matching string via next: { tags }. Useful when a single mutation should invalidate data used by many unrelated pages at once.
unstable_cache(fn, keyParts?, options?) Wraps an arbitrary async function (e.g. a database query) so its result is cached and revalidated the same way a tagged, time-limited fetch() call would be -- useful for caching data sources other than fetch(). As the name signals, its API is still in flux between minor versions.


The 'use cache' Directive

Newer Next.js versions are moving toward an experimental 'use cache' directive (enabled via the useCache / dynamicIO flags in next.config.js) that lets you mark a function, file, or component as cacheable directly, as an alternative to unstable_cache(). Treat it as forward-looking rather than the stable default until it graduates out of experimental status.