Published versions and deploy hooks
Every publish of your site is kept as a numbered version, and the Versions section of the project's Settings lists them. Deploy hooks, in the same Settings, let another tool ask Briks to publish your site again. This page covers both.
The list of published versions
The section lists the latest 100 versions, newest first. Each row shows:
- Version and its number, with a green Live tag on the one visitors see now.
- How it came about: Built, Changed, Checked and repaired or Published again, and who asked for it.
- The date and time it was published, such as 8 Oct 2026, 14:32.
- A short summary. For a change, it is the words you asked with; for a build or a fresh publish, it is what Briks did.
- Once a version has been live for a week, a line on whether it helped (see below).
| Label | What made the version |
|---|---|
| Built | A first build, or a new project copied from a template or another project |
| Changed | A change you asked for, code you saved in File Explorer, or a picture you swapped from the media library |
| Checked and repaired | A site check that fixed something it found |
| Published again | A move to production or back to preview, Apply to the live site, a new address, a domain going live, or a deploy hook. Its summary says which, such as “Published again with the site's settings.” |
For every job on the project, including ones that published nothing, see Logs.
Did the change help?
Once a version has been live for 7 days, its row gains a line that compares visits before it with visits since, for the pages the version changed, each as a week's average over up to 14 days either side. It reads, for example, “Since version 12 (Add a prices section), enquiries from /prices went from 3 to 5 a week, on similar visits.” When those pages had fewer than 25 visitors a week, it says there were too few visits to tell. A change an agent made is named as that agent's. The line is worked out from your own analytics with no AI and costs nothing. Versions that were only published again, and the first build, get no line. The latest 12 versions are read, and a read is final once 14 days have passed.
Restore a version
Find the version
Where: Settings, Versions
Every row except the live one has a Restore button, if your role lets you edit the project.
Restore it
Where: Restore version
Press Restore. The dialog says “It goes back on the live site exactly as it was published. The versions after it stay saved, so you can come back.” Press Restore version and the number.
Watch it publish
Where: Studio
Briks takes you to the studio while it publishes. The message reads, for example, “Version 12 is live again, exactly as it was published.” The Live tag moves to that row.
A restore runs no AI. Owners, Admins and Editors can restore; Viewers can see the list. It is not possible while an A/B test is running. Versions, undo and redo covers the same history from inside the studio.
What a deploy hook is
A deploy hook is a private web address that publishes your site again whenever something calls it. (To deploy is to publish.) You give the address to another tool, such as a scheduling service, and that tool calls it when it wants a fresh publish.
A call publishes the live version again from its own files, with the project's settings as they stand. No AI runs, nothing is charged, and nothing changes that you did not already change. Your site's pages are put together when it is published, not each time someone visits, so a fresh publish picks up:
- the latest published records from the site's database, for any pages built from them;
- settings you have changed since the last publish, such as the logo, the favicon or the search settings;
- anything a page works out at the moment it is put together.
It does not make changes you describe, read data from the tool that calls it, or run the launch check.
Make a deploy hook
Open Deploy hooks
Where: Settings, Deploy hooks
Open your project, click the Settings tab, then Deploy hooks in the Developer group.
Add one
Where: Add a deploy hook
Press Add deploy hook. Name it after what will call it, such as
Nightly scheduler, and press Make hook.Copy the address
Where: Your deploy hook
Briks shows the address once. Press Copy and paste it straight into the tool that will call it. Briks keeps no readable copy, so you cannot see it again later.
Finish
Where: Your deploy hook
Press Done. The hook joins the list with the date it was made and “never called”.
Hooks start working once the project has been published; until then the section says so. Owners, Admins and Editors can make and delete hooks.
Calling a hook
The tool must send a POST request to the address (the kind of web request that asks for something to happen, rather than just reading a page). Most automation and scheduling tools have a setting for this. The dialog shows the shape of a call made from a terminal: curl -X POST https://app.briks.dev/api/hooks/bdh_…, with your full address in place of the shortened one.
| When the call arrives | What happens |
|---|---|
| The site is ready | A publish starts and shows in the studio like any other. |
| A build or publish is already running | The call is accepted and joined to it, so a burst of calls publishes once. |
| The hook was called six times in the last hour | Refused: “This hook was called six times in the last hour. Try again later.” |
| The project has never been published | Refused: “The project has not been published yet.” |
| An A/B test is running | Refused: “An A/B test is running on this site. End it by keeping one version first.” |
| Neither the person who made the hook nor the one who made the project has a Briks account any more | Refused: “This hook has no owner left. Make a new one in the project's Deploy hooks.” |
| The hook was deleted | The address no longer works. |
Each call updates the “last called” time on the hook's row, so you can see your tool is working.
A worked example
Northside Running Club's site lists upcoming races from records in its database. Its organiser asked in the studio whether the races page works anything out from the date when it is published. The answer was yes: it picks the races still to come at that moment. So she made a hook called
Nightly schedulerand set the scheduling service she already used for club emails to send a POST to it at 03:00 every night.
Each morning the races page starts from that day. The hook's row shows when it was last called, and Versions gains one row a night with the summary “Published again with the site's settings.”
Bear in mind that every publish adds a version, so a nightly hook adds about thirty rows a month to Versions, and the list shows the latest 100. If you are not sure whether a page depends on the date, ask in the studio first (see Asking questions); questions are answered without a build.
Deploy hooks and webhooks
| Deploy hook | Webhook | |
|---|---|---|
| Direction | Another tool calls Briks | Briks calls another tool |
| What it does | Publishes your site again | Tells the tool that something happened |
| When | Whenever it is called | On site.published, form.received or record.changed |
| Where | Settings, Deploy hooks | Settings, Webhooks |
They work well together. A webhook on site.published can tell another tool each time a publish finishes, including one a deploy hook started (see Webhooks).
Delete a hook
Press Delete on the hook's row. The confirmation says “Its address stops working at once.” Press Delete again. Tools still calling it get no publish, so remove the address from them too.