Headless separates your CMS from your frontend. It should not leave them unaware of each other. Configure your publishing webhook and let ContioReach notify your application when content changes so the relevant frontend content can be refreshed. No manual rebuild request. No waiting for someone to tell the developer an article changed. No stale published content simply because the frontend did not know.
Your content team works in the CMS. Your users experience the frontend. When an editor publishes or updates something, the application needs to know that its source content changed.
ContioReach provides the bridge without collapsing the architectural separation.
Publish
The content team changes the published content in ContioReach.
Notify
The webhook sends the publishing event to your configured application endpoint.
Refresh
Your frontend decides how to revalidate the relevant content.
A bridge is not a coupling.
One signal is all the two systems need to share to stay in step.
ContioReach does not need to own the frontend to keep it informed.
ContioReach
Your application
The CMS sends the signal.
Your application decides what should happen with it.
Webhook configuration
Configure the publishing connection from the workspace developer settings.
Application endpoint
Send the event to the route your application uses to handle content updates.
Secure token
Use a generated secret so your application can validate the revalidation request.
Blog index refresh
Refresh the blog listing when publication changes what content should appear there.
Article refresh
Revalidate the relevant article route when the published post itself changes.
Developer control
Decide how your application handles the event rather than allowing the CMS to dictate your caching or rendering architecture.
The event carries what changed.
Your code decides what that means for the cache.
Configure
Add the application destination and secure the webhook connection in ContioReach.
Publish
Let the content team publish or update the article normally inside the CMS.
Revalidate
Receive the webhook, verify the request, and refresh the relevant content in your frontend.
Your content team publishes.
Your application stays current.
Content teams
Publish normally without needing to understand revalidation routes, caches, or frontend deployment logic.
Developers
Define the endpoint, security check, and revalidation behavior appropriate to the application.
Platform teams
Keep content delivery event driven instead of depending entirely on manual deployments or arbitrary refresh intervals.
The CMS manages the event.
Your stack manages the response.
Edit
A writer or editor changes the article.
Publish
The new version becomes published in ContioReach.
Trigger
ContioReach sends the configured webhook event.
Verify
Your application validates the secure request.
Revalidate
Refresh the blog index, article route, or other relevant content.
Serve
Visitors receive the updated published version from your frontend.
Headless remains decoupled.
Publishing remains connected.
Secure webhook
Use a generated secret token so your application can validate requests before performing revalidation.
Path aware
Refresh the content that actually changed rather than treating every publication event like a reason to rebuild everything.
API compatible
Webhooks work alongside the headless content API rather than replacing it.
The API supplies the content.
The webhook tells your application when that content changed.
Every tool your team needs to create, optimize, and scale modern blogs — built directly into one headless CMS.
We're here to assist.
Still have questions? Feel free to contact our friendly support team specialists.
A webhook is the notification ContioReach can send to your application when a relevant content publishing event occurs.
If your frontend caches or generates content, revalidation gives it a way to refresh the relevant pages after the CMS content changes.
The ContioReach webhook workflow supports a generated secret token that your application can verify before processing the revalidation request.
Yes. Your application can use the post information supplied in the publishing workflow to refresh the relevant article route according to your implementation.
No. The API delivers the content. The webhook provides a signal that tells your application when that content may need to be fetched or rendered again.
Connect the webhook. Keep your architecture headless. Let content updates reach the frontend without another manual handoff.
