Add support to `previous_entity` to `publish` event

Hello! I’m not sure if this qualifies as a feature request or a bug report (I believe it’s the former). I’m setting up a webhook to trigger on publish events in a Record to notify an API that revalidates tags on my server.

In my real scenario, I have a news item that can belong to either category A or category B, and each category has its own cache tag. When I publish a new news item in category A, a tag revalidation occurs to refresh the listing for category A. Same for B.

Now, imagine that I actually want to update a news item that’s already published, moving it from category A to category B. In this case, I want to be notified so that both caches can be revalidated. So I created a webhook like this:

  • URL: <domain>/api/v1/cache/revalidate
  • Triggers: Record / Publish / Model “News”
  • Body: custom payload

And my custom payload is something like this (compatible with my own API):

{ "tags": [ 
    "news-category-{{entity.attributes.category}}", 
    "news-category-{{previous_entity.attributes.category}}" 
] }

Note that I’m trying to pass 2 items: one with the category of the published item and one with the category of the previously published version. However, in this case, {{previous_entity}} is undefined.

What would I like to see implemented?

For publish events, it would be helpful if {{previous_entity}} contained the data from the currently published version, and only be empty if there was no previously published version. It’s important to note that I expect only “published” versions to be compared, so the comparison should be “from published (before) to published (after).”

Currently, to work around this issue, I have to revalidate the entire cache. However, it would be highly beneficial if I could revalidate only the affected categories.

Important: I tried using the “update” events, but they are triggered when I save a record, which requests revalidation before it’s published, making the system ineffective anyway.

Thank you!

Hey @contas,

Welcome to the Dato forum, and thank you for such a clear and detailed feature request! I agree that this would be a useful addition, and I’d love to see it added. Hopefully it will get enough votes and the devs can consider adding it :slight_smile:


Sometimes feature requests can take a while. As a workaround in the meantime, I think you might be able to get a similar effect by calling the CMA and requesting the previous record version manually: Record version — Content Management API — DatoCMS

Also, if you’re on Next, have you already seen our own official Cache Tags implementation from last month? That would be our recommended way to handle content invalidations whenever your frontend stack supports this system, since it automatically calculates (on our end) what content has changed.

Thank you for your attention!

Using the CMA Record Version could help in some way, but it would require a two-way implementation: notification via webhook (which is the only method I wanted to use) and executing the API on the server side to check for differences between versions (which would be the proposed workaround).

I’m using NextJS, so I’ll try the proposed solution and see how the application behaves.

Thank you!

FWIW (and probably you already know this? but just for clarification) I think it could be a Next.js API route (pages router) or route handler (app router), if that’s where you’re already handling your webhooks.

The same handler that receives our webhook POST can then make its own fetches to our CMA, inside the same handler, and then proceed to invalidate what it finds. Basically it just becomes a longer synchronous series of HTTP requests, back and forth. But it should still usually fall within serverless timeout limits.

If you’re not doing the webhook handlers in Next but somewhere like Cloudflare or AWS Lambdas, I think the same principles would still apply.

Hopefully that works!

Yes, your suggestion could work. If it takes too long to get an update on this topic, that’s likely what I’ll do. However, first, I’ll look into how efficient the Cache Tags proposed by your team are. If they work as I expect, it might be better than introducing my own tags. :slight_smile: Thanks a lot!

1 Like