BUILD_ID Availability in Deploy Notification Webhook

I am experiencing the same issues that I’ve seen others post about in the forum where my old asset files are not saved, Chunk Load Errors occur, and my website “breaks” when I push a change. I deploy updates many teams a day/week, so this behavior doesn’t lead to the best end-user experience (especially if they don’t know to refresh the page).

I don’t know if this is possible, but I am exploring the Deploy Notification webhooks and want to see if the Build ID (or some other value unique to the deploy) variable is available to the webhook. I’m envisioning sending the completed webhook to my own site, handling it with a lamda-function, and storing the variable in the database. That way, I can programatically check if the user is on the most recent version of the website, and if they are not, provide a prompt for them to refresh the page. I see this replacing the not so pretty way of catching Chunk Load Errors (for JS and CSS) which is not so easy to test and not the best solution for me.

Is this possible? I believe it makes way more sense than any other approach. I absolutely love Netlify, but having constant errors due to deploying non-breaking updates/changes doesn’t seem right.

Edit: Maybe this flow would work?

  • Successful build hook to sent lambda function on site
  • Lambda function does a GET /api/v1/hooks?site_id=:site_id with the site_id and Oauth credentials saved as netlify variables
  • Get the SiteID from the response, save it to the DB
  • Save the site ID to a local variable on user’s browser. Compare local variable with what is saved in DB- if differs, notify user a newer version of the site has been released and prompt the user to refresh.

Any input from an experienced dev is greatly appreciated.


Also, is there a way to trigger an outgoing webhook without going through the build process for testing purposes?

Hiya @lilbigwheel and sorry to be slow to get back to you!

This thread describes the chunking dilemma and some workarounds:

The webhook notification body (for a completed build) from us around a build should contain all kinds of unique identifiers including the deploy ID and site ID in the JSON - are you not seeing that?

The flow you describe doesn’t sound totally weird but is a bit roundabout - I think I would just use a static version.txt file and check that when a chunked resource 404’s, and force a hard reload in case of that 404.

Or…maybe not use chunks since that simplifies things? Not sure if that is practical for your app.

Re: triggering outgoing webhook without building, only the failed build ones, I guess. You could potentially replay the contents of an old hook with small modifications, using postman or a similar tool, I suppose?

1 Like

I’m also exploring the use of a version.txt file. Is the netlify build_id considered a “secret”, or could it be used for this purpose? If it’s best not to make that id public, do you have any thoughts how a version number could be incremented on each deployment?

1 Like

hi there,

by build ID do you mean the API ID (which is a alphanumeric sequence that looks like this example:

that number is safe to share, nobody can do anything with it (except Netlify staff).

there is also the deploy ID which looks like this: 74777123 which uniquely identifies the specific deploy.

nobody can really do anything that either, so both are safe to share.