I am literally hitting a brick wall here. I am using pipedream to get form data from webflow, run a cloud function and then update a CMS collection with the result of the cloud function using the update collection item API.
Even though the CMS update supposedly updates the live site (I have added the option live = true in the API call), this doesn’t happen. I have to refresh the page, and only then does the new image show up.
I would have expected that the whole point of CMS update API is to automatically update images. Looking at the collection, from the designer, i need to refresh the page here as well to see the changes.
Why is this so complicated? Its such a simply workflow.
It sounds like there is a bit of confusion on your part.
The whole point of the API is to update the CMS automatically, which it sounds like it did, not reload content on your web page.
What you’re experiencing is correct behavior. You must reload the web browser before you’ll see the changes on your live site.
That’s not really a Webflow issue, thats just how the web works. If you update a database (CMS) that is you attach to a website, unless you program it otherwise, you need to reload the web browser to see it. It’s very common.
You have the option to program it to auto-update content on your page if you like, but that’s not included by default with Webflow, and it’s not a common approach with Webflow.
That means that the data will be published to the live site within the CMS, versus other options like staging, or draft.
Here’s an overview of all the different publishing states:
The thing is if i just used a simply fetch api in JS i would get the response directly on the page. All i want to do is to get the response from a post request. Are you saying I cannot do that with the API?
I guess what I am trying to avoid is to write out an API call in javascroipt that would be able to fetch the result and display it on success. I have the API running in pipedream and all i want is to return to response to the page. Is there any way I can do that?
Ok, thank you so much! That is really helpful, I actually read this blog and was secretly hoping that I didn’t have to change my workflow, but it looks like the response is yes. I will keep you updated with how it goes and thanks for clarifying how the api works.
As Chris covered, Webflow effectively delivers static pages, so your browser has no idea that the CMS has updated until you refresh. This is how most websites work unless you build an AJAX update infrastructure into your UI.
That gives you two options.
Perform your CMS live update ( via a form post? ), and then when you get the success response back, do a javascript refresh of your page.
Perform your update, and also return the new information you want the browser to have. Parse that JSON response to update your UI dynamically with new HTML.
#1 is the easier one, and the one I use in most scenarios. #2 is more AJAX-like, but really only necessary when you’re shipping data outside of the CMS. Here a refresh is all you need so I’d do #1.
Pipedream is perfect for this, and if you’re a programmer you’ll likely find it much easier to work with than Make. Differences- Pipedream is more linear, Make is graph-oriented. Pipedream is code-based which gives you clean, precise control, Make is simpler for no-code users, but abstracts you from sometimes-important underlying mechanics.
Both offer webhook request and response support well, which means that you can return data or a success response using either stack.
Switching from Pipedream to a free Make account was a suggestion so that you could follow along with that screencast and find quick success.
With a quick win you’ve now gained a new skill and you can take that new skill gained to any other service that offers it.
Those learnings are transferable
That said, unless there are distinct benefits for you with Pipedream, it’s typically the wrong solution for folks around here.
The costs are about double (yearly), and triple (monthly) versus Make.
It’s a lot more difficult to work with as it’s UX is more similar to Zapier - though, less so if you’re already familiar with it.
Lots of hidden costs with Pipedream.
As just one example… there’s no (easy) way with Pipedream to filter requests and not be charged for them, like you can in Make. When you unexpectedly get a volume of traffic that has a big impact on costs.
