Hello
I want to set up a store that uses an API to fetch the pricing of the products, and they constantly change (similarly to stock).
Is it possible to achieve on Webflow?
If so, what would be the workflow?
Thanks
Hi Guy,
I haven’t built this but it should be possible.
I assume you’re talking about prices in some external system that you need to query, maybe add on a % surcharge, and then update that product in Webflow.
You’d engineer this outside of Webflow as some form of scheduled nightly automation that;
- Gets the list of products to update
- Goes and gets the current price
- Updates the associated Webflow SKUs
For simplicity I’d probably maintain the list of SKU’s you’re updating + the remote product ID in some external service like Airtable.
Also, I’d probably store the current price in Airtable as well so that you are only updating Webflow when the price has changed, The reason is the API limits in Webflow, you want to minimize traffic there to minimize complexity of load-management.
Here’s the Webflow API you’d call to perform the update.
Thank you
It’s almost what I need, but the problem is I need the price to constantly change, at least once every second.
Is there a way around this?
I definitely wouldn’t use Webflow ECom for that. Say you have only 100 products. that means 100 * 60 = 6,000 API requests per minute. The current API limit is in the neighborhood of 100 to 150 per minute.
The ECom solution you use will depend on a lot of factors… cart behavior, taxes, user account history, etc, but they key thing you need is the ability to hand it an arbitrary price when the item is added to the cart.
I think Foxy cart should be able to do that, so the rest is Javascript, ensuring that at the moment the user clicks Add to Cart, we have the ability to give it the current price per unit.
You’re building some form of dynamic feed here, which would probably have two parts.
- Server-side piece would collect the prices, make any adjustments, and store them in a table. It would update those prices every second, and expose a simple client-facing API.
- Client side piece is javascript that would hit your own mini API ( thus no API limits ), grab the current prices, and the update the webpage and e-commerce data layer accordingly.
It’s an intriguing problem, but tbh it has some complexities. Is the price changing dynamically while users are looking at the page? Between the time a user clicks “add to cart” and the time they pay, the price has already changed at least 30 times…
Thank you
I was actually thinking of using Webflow alone and instead of calling Webflow API, have the client side read the prices from an external API and then, uppon “add to cart”, there’s some missing piece in the puzzle for me on how the price will safely change based on that.
With Foxy, How does the system make sure that the price they pay is actually the one set uppon the “add to cart”?
I mean, you have toe set up a fixed price on the eCom system, how would you just ignore that price and “inject” a price from outside?
I’m ok with the price being set on “add to cart” and stay that way until they pay, it doesn’t have to be that accurate :)
Foxy is not related to Webflow ECom, it just handles your cart UX, the checkout and payment processes, email notifications, etc. It should be able to use whatever price you give it.
Typically you’d store your products in a standard CMS collection, emit them into the page, mark them up with attributes and Foxy would then know where to find the product name, price, quantity etc. for the add to cart.
Since that’s all client-side, there’s nothing to prevent you from just changing the price up until they click add to cart. After that, Foxy has captured the data, and I don’t know what options you might have to update it, so It’s likely “frozen” through the checkout process and users would expect that anyway.
That’s the key tradeoff for the flexibility you’re wanting. Arbitrary pricing means the price itself is exposed to tampering for someone with the knowhow.
So yes, someone technically proficient could absolutely add stuff to the cart, hack the prices, and complete the checkout. You might talk to the team at Foxy to see what they could recommend for your unusual setup here.
I’m not sure you could prevent it, but a fairly advanced implementation might be able to do some form of tamper detection. Something like this;
- Your server API generates its prices. When your client code requests it, it also gets a PK-signed JSON chunk containing all of the prices. This is the server’s seal of approval that those are the official prices according to the server.
- Client side simply receives that signed chunk ( in addition to the plain JSON data ), and then submits it with the order as a custom order field, so that it’s part of the order history itself.
- Order completes, and you receive the data including those custom fields.
- You then have a separate “tamper detection” process which verifies the signature on that chunk, and then compares those prices to the individual prices that were paid in the order. Any mismatches on the sig or the prices, it yells foul and notifies your team, and it does not proceed into order fulfillment.
Just want to add, while these engineering problems are fun to solve, they’re not particularly trivial to implement. I hope you’ve got a solid reason you’re needing this level of complexity.
Thank you
Can’t Foxy just take the pricing from my Airtable after it’s added to cart, without caring what the client actually saw? So they wouldn’t be able to tamper it
Airtable? You’re likely to have issues with your 6,000 updates per minute ( per 100 products ) there as well. Airtable is known for its UX, not for its ability to operate as a live database.
No I seriously doubt Foxy would have an Airtable adapter, that’s a very unusual edge case, I can’t imagine what use it would normally have. Talk to them though.
Doubtful. The cart is in memory on the browser, which means someone with the right knowledge could access it and change the prices even after they’ve been added to the cart.
That’s why the tamper-checking would be needed for a dynamic pricing model, if you’re seriously considering it.
If you want to go server-to-server, another approach might be to use Stripe for your checkout directly. They’re recently added some form of cart functionality as well, if you need to do multiple products at a time.
Stripe’s designed to operate as the backbone for some traffic-intensive APIs, and could probably handle your 6,000 API updates / min / 100 products. To my knowledge Stripe still does not support arbitrary pricing- so there’s no chance of tampering. You’d just solve the “dynamic” part by updating it server-side.
Check the API docs though. For 100 products, that’s 8.64 million API calls per day. I think I’d buffer that unless your product pricing is actually changing every second.
Hi @Guym88.
Josh with Foxy here. Interesting use case. Product data could be managed in Airtable. Then use Whalesync or PowerImporter to sync data to Weblow CMS. Though, you’re going to run into some issues if pricing changes as often as you’ve mentioned.
Can you clarify on how much/often pricing will change? We have a pre-payment webhook that you can use to check Airtable to ensure product pricing in cart matches what’s in Airtable, but as @memetican mentioned, if pricing is changing constantly, how does any of the involved systems know what the price should actually be?
I’m really curious to learn about your use case and how often “constantly” is. Inventory changes happen often and can happen more often during sales and special events, but that’s usually pretty easy to maintain/sync.
Thanks,
Josh
Thank you Josh @foxy
I think my use is very common, maybe I didn’t explain it properly - it’s simply a shop that let’s users buy products that are tied to a commodity price, eg gold, silver, etc.
Each product has its own multiplier, and it justs need the current commodity rate and multiply it in the multiplier to get the pricing.
Every commodity exchange, currency exchanges, and even NFT exchanges have that capabilities.
I hope that helps?
Also, how about using the Webflow logic + webhook to update the prices directly in the CMS? Why is that not an option?
I like that you’re thinking through the solution paths. The mark of a problem solver.
There are a lot of reasons Logic wouldn’t fit here, but I’ll give you two;
- Stability. Logic isn’t particularly stable, and will completely shut down if something goes wrong. In fact, most automation SaaS platforms ( Zapier, Make, etc. ) will shut down an automation when they see a series of errors, so this isn’t a good approach for a robust system.
- Cost. Logic costs one “form submission” per run. Once you exceed your monthly form submissions, you pay 1 cent per additional submission. For what you’re building so far, that’s $86,400 per day, per 100 products. Webflow would love you though.
That’s clearer, but that doesn’t mean that dynamic pricing is a common feature of ECommerce SaaS platforms.
I think you’re probably approaching your product search in the wrong direction. Instead of picking a platform and trying to make it work, start with your central requirement which is the dynamic pricing. and then…
- Investigate the largest ECommerce-focused SaaS solutions out there, Shopify, etc. to see if someone has built extensions to support what you need.
- Go to ECommerce-focused forums and explain what you’re looking for. Others may have experience with a platform that has those capabilities, or a similar project they’ve worked on that they can offer guidance.
Besides the mechanics of the pricing update, you really need to think about how a cart will work in this environment. Are the prices they see in the cart still changing, in realtime? Are they just estimates? Or are they fixed at the moment the project was added… and if so, how long is the cart valid at that promised price? A lot of UX and business rule mechanics to work out.
Thank you
What if we simplify the problem -
the prices only update once a day, by either manually updating the gold price and then have it reflect on all products, or by automatically somehow?
When products are in the cart their pricing will be updated too, or they’ll see a warning “refresh to see updated prices”.
I think we can then use Webflow’s API, correct?
But question is how do we update the UI on all visitors to let them know the prices are no longer correct, or even better - update the prices seamlessly.
Any other problems we might have in this case?
You like complexity don’t you?
I’m going to need to start charging engineering time. 
Once a day solves a lot of issues.
When the price changes;
- The webpage the user is on won’t know anything about a price change.
- If the user navigates to a new product, that new product will have the updated price
- It’s unlikely ( but possible ) that the existing cart items added before the price change will be updated. Depends on Webflow’s cart architecture, you’d want to test that first to see if it’s an option.
Notifying users, again the webpage doesn’t know what’s happening on the server, it’s just a document. You could integrate some kind of push notifications system, or else you could write a pre-built notification in client side JS that just fires at e.g. midnight GMT.
You can set up a store with dynamic pricing using Webflow by integrating APIs for real-time product price updates.
@Guym88.
Once a day price changing definitely simplifies things. At the end of the day, Foxy is simply looking for the product name, price, etc. that needs to be added to cart. You can then use our pre-payment webhook to check prices (from CMS, Airtable, etc.) to ensure they haven’t changed since the product was added to cart.
Please don’t hesitate to reach out if you have any follow up questions or need help getting started: hello@foxy.io
Thanks,
Josh