When using the Sitefinity Next.js SDK with the App Router, configuring SDK cache settings such as SF_SDK_CACHE_REVALIDATE, SF_SDK_CACHE, or per-request additionalFetchData with next: has no effect. The Next.js Data Cache never hits because every request produces a different cache key.

This results in every page load making fresh API calls to the Sitefinity CMS regardless of the cache configuration, leading to degraded performance and elevated TTFB (Time to First Byte).

Next.js Data Cache generates cache keys from the full fetch(url, options), including headers. The Sitefinity Next.js SDK's RestClient.sendRequest() unconditionally injects per-request headers into every fetch() call, making the cache key unique per request. Three sources contribute to this:

1. Random correlation ID (proxy/headers.js): The getProxyHeaders() function generates a random 16-character string for x-sf-correlation-id on every call. This alone guarantees a unique cache key on every fetch.

2. Forwarded browser headers (rest-client.js): The getFilteredServerSideHeaders() function reads incoming browser request headers via next/headers and forwards them into the CMS API fetch. Headers like user-agent, sec-ch-ua, sec-fetch-dest, if-none-match, etc. vary between requests and browsers, producing different cache keys.

3. Forwarded cookies (rest-client.js): Browser cookies (session IDs, CSRF tokens) are forwarded into the fetch headers. These change between requests and sessions.

The header and cookie forwarding serves legitimate purposes: browser headers enable Sitefinity's personalization and language detection features, and cookie forwarding is essential for authenticated edit/preview mode. However, the forwarding is unconditional — it applies equally to anonymous cached fetches and authenticated edit mode fetches, creating a conflict between the SDK's caching configuration and its header-forwarding behavior.

None at this time.

The following workaround options can be applied using patch-package (or a similar tool) to restore effective Data Cache behavior.

Option 1: Pin the correlation ID to a stable value

In proxy/headers.js, replace the random correlation ID generation with a stable value so that cached fetches share the same cache key:

     if (!headersCollection['x-sf-correlation-id']) {
-        headersCollection['x-sf-correlation-id'] = generateRandomString();
+        headersCollection['x-sf-correlation-id'] = 'nextjs-render';
     }

Trade-off: Renderer-to-CMS log correlation will no longer be per-request. This is generally acceptable in production scenarios where caching is the priority.

Option 2: Exclude per-request and per-visitor headers from cache-eligible fetches

In server-side-headers.js, add per-request/per-visitor headers to the exclusion list and exclude Azure Front Door header families by prefix:

const HEADERS_TO_EXCLUDE = [
    'accept-encoding',
    'accept',
    'accept-language',
    'cookie',
    'host',
    'content-length',
    'x-forwarded-for',
    'x-real-ip',
    'x-request-id',
    'request-id',
    'x-correlation-id',
    'referer'
];

const HEADER_PREFIXES_TO_EXCLUDE = ['x-azure-'];

export async function getFilteredServerSideHeaders() {
    if (typeof window === 'undefined') {
        const headersModule = await import('next/headers');
        const headersList = await headersModule.headers();
        const requestHeaders = headersList ? Array.from(headersList) : [];
        const filteredHeaders = requestHeaders.filter(([name]) => {
            const lower = name.toLowerCase();
            return !HEADERS_TO_EXCLUDE.includes(lower) &&
                   !HEADER_PREFIXES_TO_EXCLUDE.some((prefix) => lower.startsWith(prefix));
        });
        return Object.fromEntries(filteredHeaders);
    }
    return {};
}

Alternative Option 2 (more comprehensive): Conditionally skip all forwarded headers for cacheable fetches

In rest-client.js, within the sendRequest() method, conditionally skip browser header and cookie forwarding when the request is cache-eligible:

const isExplicitNoStore = request.additionalFetchData?.cache === 'no-store';
const isCacheable = !isExplicitNoStore && (
    request.additionalFetchData?.next?.revalidate != null
    || request.additionalFetchData?.next?.tags != null
    || process.env.SF_SDK_CACHE_REVALIDATE
    || process.env.SF_SDK_CACHE
);

if (!isCacheable) {
    // Forward browser headers and cookies only for non-cacheable requests (e.g., edit mode)
    const headerKeys = Object.keys(headers).map(x => x.toLowerCase());
    const serverSideHeaders = await getFilteredServerSideHeaders();
    if (serverSideHeaders) {
        Object.entries(serverSideHeaders).forEach(([headerKey, headerValue]) => {
            if (!headerKeys.includes(headerKey.toLowerCase())) {
                headers[headerKey] = headerValue;
            }
        });
    }
    const cookie = await getServerSideCookie();
    RestClient.addAuthHeaders(cookie, headers);
}

This approach preserves full header and cookie forwarding for edit/preview mode (which uses cache: 'no-store') while omitting them for cacheable anonymous fetches.

Result after applying the workaround should be as follows:

get 250468ea... [ 'pages' ] FETCH true ← same hash, cache hit

get 4bfbe4b9... [ 'site-messages' ] FETCH true

get 5018d8e0... [ 'menus' ] FETCH true

The Data Cache hit rate goes from 0% to 100% on subsequent page loads within the revalidation window.

• Edit mode continues to work correctly with these patches, as edit mode fetches pass { cache: 'no-store' } via additionalFetchData, which bypasses the caching logic and forwards all headers and cookies as before.
• If your deployment uses a CDN or reverse proxy (e.g., Azure Front Door), the header prefix exclusion for 'x-azure-' is particularly important as these headers are unique per request.

References to Other Documentation:

1. Sitefinity Documentation, Configure cache https://www.progress.com/documentation/sitefinity-cms/next.js-configure-cache