Any plans to allow data cache purging from REST API?

It seems like this feature can only be invoked via the Vercel console under Settings > Data Cache. Are there plans to allow this from the REST API?

I ask because the data cache seems to be out of sync and I need to manually purge whenever my data changes - which is approximately once per day. I need to do this even though I have a cron job that calls an API route of mine that performs a combination of on-demand and tag (via revalidateTag and revalidatePath) based revalidation. This technique works sometimes, sometimes it takes several attempts, and sometimes it doesn’t work at all. Shouldn’t these techniques also force the data cache to be purged?

1 Like

Hi @lsli8888, welcome to the Vercel Community!

No, we don’t have an API to do cache purging. You should be able to get the cache invalidation or purging by using Data cache examples.

Can you share your code so we can see why the caches might not be invalidating on time?

Hi @anshumanb. I’ll share some snippets of code at a high level, but unfortunately I cannot share all the code or the exact code.

What I can say is that the app uses nextjs 14.2.3 (app uses app router), Drizzle ORM 0.38.4 to perform database queries against a Supabase Postgres database. The db calls are cached using unstable_cache with a tag specified and a revalidate time of one day. My database queries follow this pattern:

export const invokeCachedDbQuery = unstable_cache(
  async (param) => {
      param
    );

    return invokeDbQuery(
      param
    );
  },
  [],
  { tags: "mytag", revalidate: 86400}
);

I also have a Vercel cron job that invalidates this cache every day by invoking a route whose business logic invalidates the cache using the tag:

export async function GET(request: NextRequest) {
  revalidateTag("myTag");
  revalidatePath('/', 'layout');

  const response = NextResponse.json({
    success: true,
    message: 'Caches invalidated',
  });

  response.headers.set('Cache-Control', 'no-store, no-cache, must-revalidate, proxy-revalidate');
  response.headers.set('X-Robots-Tag', 'noindex, nofollow');

  return response;
}

Many of my pages (page.tsx) are also invalidated once per day:

export const revalidate = 86400;

Strangely, this API call seems to work sometimes to invalidate the database cache, but there are times when it seemingly doesn’t. That’s when I resort to purging the data cache from the Vercel console. This method of purging the cache via the Vercel console always seems to work though, and that’s why I was hoping Vercel would make a RESTful API endpoint to allow for this so I don’t have to manually purge the cache everyday.

I wish I could provide more details, but this is the best I can do. Not sure if you can provide any help with these limited details, but I would definitely appreciate any advice or info. Thanks!

Hi @lsli8888, thanks for sharing the code snippets.

You seem to be using the cache features correctly. The only things I’d have you double check are:

  • ensure you use tags as an array of strings instead of a string
  • make sure the tags are same across tags array and revalidateTag
  • the server functions that use this cached calls should not be cached themselves

Let me if this helps

1 Like

Hi @anshumanb,

Thanks for the reply. It’s affirmative to your first two bullet points - as I only have one tag and it’s defined/referenced using a global variable.

On bullet point three, I’ve got a React page component (e.g. page.tsx) which invokes the cached calls. The page component has incremental static regeneration defined to be revalidated once per day:

export const revalidate = 86400;

Not sure if this is causing issues - but shouldn’t my API route that invalidates the tags along with these pages (since I use):

revalidatePath('/', 'layout');

Shouldn’t this take care of invalidating the cached db calls and the pages themselves? Thanks!

Hi @lsli8888, I see.

Can you please share your public repo or a minimal reproducible example. That will let us all work together from the same code to figure out what’s going wrong.