How to update Divhunt's CMS from a database via the REST API?

How can I populate/update Divhunt’s CMS from a database using the REST API?

The discussions I’ve read here about the REST API seem to be about displaying data directly from an external source (e.g. Airtable, Strapi) instead of updating Divhunt’s CMS.

I want to:

  1. Use a database as the backend (“single source of truth”) for all data collection and manipulation.
  2. Update the Divhunt CMS via the REST API so they’re in sync.
  3. Display the data from the CMS in Divhunt (not directly from the database).

For the database, I’m using, which has an API. But I imagine the solution is probably similar for Airtable, Strapi, etc.

Thanks in advance for your help.

I am not sure if I understand, you want to use 3rd-party database but replicate data to Divhunt CMS, or?

@dejan Yes, I want Divhunt’s CMS data to be in sync with a 3rd-party database so l can build more complex apps using Divhunt as the front end.

This is a common no-code app approach where:

  • Backend = The database (e.g., Airtable, AITable, Supabase)—Serves as the single source of truth for app data. Allows data manipulation.
  • Logic = API or some automation software (e.g., Zapier, Make, ActivePieces)—Syncs data from the database backend to the CMS.
  • Front end = Website (e.g., Webflow, Divhunt)—Displays data from the CMS.

I’ve seen this called the “AWZ” no-code stack (Airtable + Webflow + Zapier). Different apps can substitute for these components (e.g., AITable + Divhunt + ActivePieces). Divhunt replaces Webflow. :grinning:

As an example, there are marketplace platforms like The Unicorn Factory using this approach. The creator documents this approach on his YouTube channel and goes into detail in a Webflow No-Code Conf 2021 video.

But my initial goal is just to use a database (AITable) for gathering client data and then syncing that to the Divhunt CMS for display.

The main reason I want to sync to the CMS is that I’m thinking the pages will load faster from the CMS than when pulling data directly from the database via API calls.


Wouldn’t it be easier to just display data directly to Divhunt from AITable? In that way you’ll have data only in AITable while displaying the same data in Divhunt (Front-end).

Or there there any benefit of having duplicated content and setting up the Zappier to do so?

It is possible for sure, just trying to understand.

@dejan Yes, it would be easier to just display data directly in Divhunt from AITable, without a separate step of replicating to the CMS.

(Divhunt is the first low-/no-code site builder I’ve found that allows using a REST API directly like this. Webflow can’t. So I’m thinking through the pros and cons.)

Here are some concerns about using the REST API vs. the CMS to display data in Divhunt:

  1. Speed: Wouldn’t using API calls to pull data from an external database on page load be much slower than getting data from the internal CMS?
  2. Data fallback: If the database’s API or performance goes down, Divhunt’s CMS still has the data to display (from the last “sync”). You can also swap out databases more easily if the CMS has a copy.
  3. Divhunt CMS specialization: Divhunt has CMS-specific features that seem more flexible than just pulling in raw data via the REST API. For example, Divhunt’s CMS interface makes it easier to manage SEO and image metadata. It can also dynamically show/filter/sort data, etc.
1 Like


REST API has caching capabilities, so the speed isn’t an issue. You can cache requests for like 1 day, so only the first request will be slower, which isn’t noticeable that much.

For SEO you can achieve the same, just create a few extra fields and manage SEO at AITable.

And for fallback, maybe, but you would need to go over the website and adjust the source to come from CMS and not REST API anymore in case of failure.

It sounds like I am trying to convince you to not use our CMS, instead I just don’t see point of using 2 databases and making your life harder :smiley:

But if you decide to do it that way, we don’t have public API yet for collections with permissions, but we have master API key for your website, which can perform any API endpoint, I can send you that and short docs for CMS to create\update\delete.

AITable should also have filtering? But I guess it would be a bit harder to implement it that using native Divhunt CMS filtering.

1 Like

@dejan Thanks for helping me think through this use case.

I’ll use the direct REST API approach for now (no CMS).

But if you decide to do it that way, we don’t have public API yet for collections with permissions, but we have master API key for your website, which can perform any API endpoint, I can send you that and short docs for CMS to create\update\delete.

Please post the short docs you mention above in this thread. It would be good for the community to have that info for future reference.

Question: Are there plans to eventually have a public API for collections with permissions in Divhunt? Maybe as part of memberships?


@Bryan - I have just launched a site that utilizes REST 100% and I can vouch that it works extremely well.

And if you run into trouble, @dejan and the team are like superheroes and address issues really fast (and even implement new ones on the fly if they can).

Hit me if you have any questions on how we solved a lot of stuff using REST only :+1:t3:

1 Like

@MixxMaster That’s great to hear. Thanks!