Next.js App Router: ISR with Cookie-Based Device Token API
Unanswered
Sphecid wasp posted this in #help-forum
Sphecid waspOP
Category: Next.js / App Router / Caching Tags: ISR, generateStaticParams, cookies, device-token, region
Problem
I am building a streaming/content platform with Next.js App Router. I want to statically generate pages using generateStaticParams and enable ISR (revalidate: 1800), but my backend API requires a device token in every request header. The device token is generated by registering a device ID with my backend, which then returns a token based on the user's IP/region.
The page content (sections, feature banners, etc.) is identical for all users in the same region — so ISR should theoretically be possible. However, the cookie-based device registration is breaking static rendering.
Current Setup
• Next.js 15+ App Router with [slug] dynamic route
• generateStaticParams fetches page slugs using a device token
• Page component calls getSubPageDetails() which internally uses cookies
• export const revalidate = 1800 and export const dynamicParams = true are set
• Build succeeds with symbol (SSG) next to /[slug] in build output
Error / Symptom
During build, the following warning appears for every route:
Device registration skipped: Error: Dynamic server usage: Route /[slug] couldn't be rendered statically because it used
After running npm run build && npm run start, all page responses return:
cache-control: private, no-cache, no-store, max-age=0, must-revalidate
The x-nextjs-cache header is absent entirely, meaning ISR caching is not being applied.
Root Cause (Understood)
The Page() component calls getSubPageDetails() in a server component which reads cookies() internally. This dynamic API usage opts the entire route out of static rendering, overriding revalidate = 1800 and producing no-cache responses — even though the content is region-identical and doesn't need per-user personalization at the page level.
Question
What is the correct pattern to achieve ISR with a token-authenticated API where:
Problem
I am building a streaming/content platform with Next.js App Router. I want to statically generate pages using generateStaticParams and enable ISR (revalidate: 1800), but my backend API requires a device token in every request header. The device token is generated by registering a device ID with my backend, which then returns a token based on the user's IP/region.
The page content (sections, feature banners, etc.) is identical for all users in the same region — so ISR should theoretically be possible. However, the cookie-based device registration is breaking static rendering.
Current Setup
• Next.js 15+ App Router with [slug] dynamic route
• generateStaticParams fetches page slugs using a device token
• Page component calls getSubPageDetails() which internally uses cookies
• export const revalidate = 1800 and export const dynamicParams = true are set
• Build succeeds with symbol (SSG) next to /[slug] in build output
Error / Symptom
During build, the following warning appears for every route:
Device registration skipped: Error: Dynamic server usage: Route /[slug] couldn't be rendered statically because it used
cookies.After running npm run build && npm run start, all page responses return:
cache-control: private, no-cache, no-store, max-age=0, must-revalidate
The x-nextjs-cache header is absent entirely, meaning ISR caching is not being applied.
Root Cause (Understood)
The Page() component calls getSubPageDetails() in a server component which reads cookies() internally. This dynamic API usage opts the entire route out of static rendering, overriding revalidate = 1800 and producing no-cache responses — even though the content is region-identical and doesn't need per-user personalization at the page level.
Question
What is the correct pattern to achieve ISR with a token-authenticated API where:
3 Replies
I don't think you can use ISR for something that's behind something dynamic aka cookies, what might be a better approach is to use next 16 cache components, then use 'use cache: private' (for data that is user related this will cache on the clients browser)
Or for data that is behind something dynamic but not user specific data 'use cache: remote' which to my understanding will cache across deployments behind dynamic data
Or for data that is behind something dynamic but not user specific data 'use cache: remote' which to my understanding will cache across deployments behind dynamic data
@Sphecid wasp this will allow you to server a cached shell and leave holes for the dynamic data with suspense and if your using vercel everything static is served form a cdn
The problem is with SSG and ISR the data has to be known at build time or revalidated. And if the user has to be authenticated to access the data, the build doesn't have a user