# Cache behavior of content-api

**URL:** <https://forum.builder.io/t/cache-behavior-of-content-api/5988>\
**Category:** Technical Questions\
**Created:** [July 12, 2024, 11:22pm UTC](https://forum.builder.io/t/cache-behavior-of-content-api/5988 "2024-07-12T23:22:53Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![johnk](https://avatars.discourse-cdn.com/v4/letter/j/59ef9b/32.png) [@johnk](https://forum.builder.io/u/johnk)\
**Post date:** [July 12, 2024, 11:22pm UTC](https://forum.builder.io/t/cache-behavior-of-content-api/5988/1 "2024-07-12T23:22:53Z")

</div>

I am using the content-api within Next JS app, with an explicit cacheSeconds and staleCacheSeconds. The code looks as such:

const page =  
(await builder  
.get(‘page’, {  
userAttributes: {  
urlPath: urlPathValue,  
cacheSeconds: 3600,  
staleCacheSeconds: 3600  
},  
})  
.toPromise()) || null;

My question is whether a publish of the page is expected to invalidate the cache? Or should I expect the newly published update to an active page will take up to 3600 seconds to reflect through this API request?

---

<div class="post-metadata">

**Author:** ![Stephane](https://avatars.discourse-cdn.com/v4/letter/s/dfb087/32.png) [@Stephane](https://forum.builder.io/u/Stephane)\
**Post date:** [July 16, 2024, 8:48pm UTC](https://forum.builder.io/t/cache-behavior-of-content-api/5988/3 "2024-07-16T20:48:22Z")

</div>

When using `cacheSeconds` and `staleCacheSeconds` with the Content API in [Builder.io](http://Builder.io), the behavior of cache invalidation aligning with page publishes can be understood better through the documentation.

### **Cache Invalidation on Publish**

When you publish a page, it ideally should invalidate the cache to reflect the latest changes. However, there are nuances to this process:

1. **Cache Control with** `cacheSeconds` **and** `staleCacheSeconds` **:**

- `cacheSeconds`: This sets the maximum age of the cache-control header response header. A higher value can improve performance by reducing frequent fetch requests.
- `staleCacheSeconds`: This leverages `stale-while-revalidate` for serving stale responses while updating the cache in the background for maximum performance.

### **Expected Behavior on Publish**

Publishing new content or updates to an existing page typically should invalidate the cache immediately so that the latest changes are available to end-users without waiting for the specified cache duration:

1. **Content Fetching and Cache Invalidations:**  
If you have set `cacheSeconds` to 3600 seconds and `staleCacheSeconds` to 3600 seconds, a newly published page should ideally reflect immediately due to cache invalidation triggered by publishing action.

2. **Practical Expectation:**  
Realistically, there might be slight delays before the edge cache updates propagate completely. But `stale-while-revalidate` ensures that even if there is cached content available, it fetches the latest in the background and updates the cache.

### **Example:**

Your current code with `cacheSeconds` and `staleCacheSeconds` setup:

```auto
const page = (await builder
.get('page', {
userAttributes: {
urlPath: urlPathValue,
cacheSeconds: 3600,
staleCacheSeconds: 3600,
},
})
.toPromise()) || null;

```

For more information, you may refer to:

- [Content API](https://www.builder.io/c/docs/content-api)_file-diJsn0dA4rDf2KlpvZHM52Tn\_\_file-diJsn0dA4rDf2KlpvZHM52Tn_

This should clarify the behavior of caching and cache invalidation related to publishing content in [Builder.io](http://Builder.io).