I would like to link Business Catalyst to Veeqo to get stocks of a product and its variants stocks levels to my app but the API does not provide a direct info about this specific query request to get only that.
If I make a product request to https://api.veeqo.com/products?page_size=1 to get 1 product sample it returns too much data aprox 120kb plain .json quite more than needed so to avoid useless data I want to get just the current stock of the product variation or if a product doesn’t have variants just its own stock but this step I will handle in my request.
I noticed that there are some objects from the response I don’t need like channel_products can we just query them in the url request like &channel_products=false ? or some other way to avoid the unnecessary data float?
Unfortunately, there isn’t any way to alter the response from Veeqo. The way to get the smallest response is it request a single product by using an ID.
Specifically sending a GET request to products/:ID
What you’ve come across is a CORS problem. This is a security issue when you are trying to request the API from a web front end - normally javascript. This is due to the XSS security built into Veeqo, Rails and Ruby. There is no quick fix to this (trust me, I’ve tried really hard!)
The easiest way is to make your API requests using PHP CURL. This example in our API GitHub shows how to do that and to talk to a front-end.
I can provide you a lot more information on CORS if you want, and a lot of solutions that just don’t work.
Thanks for the info, Unfortunately, Bc is built on a .NET environment so PHP is no use right now.
I checked the documentation of BC and the Documentation for API server to server communication is only authorized using OAuth 2.0 that’s why I never had a problem using Google services and some other API used in my apps, so I believe that at the moment I cannot make calls to Veeqo with the current settings in place until they implement OAuth 2.0<, according to BC even if I make it work in the server I may leave the server at risk of security breach.
Do you think Veeqo devs will come to implement OAuth in the future?
Does it mean that Veeqo is currently vulnerable to hack attack?
It seems the documentation you’ve linked to is more referring to BusinessCatalyst, and how the integration works on their side using OAuth 2.0 rather than the other service (Veeqo in this case) you’re connecting to. After looking at the BusinessCatalyst API docs, it seems their API is more of a Javascript API available on their apps for changing content on the app itself, and has no way to import data on the server level.
That means you’re going to have to connect to Veeqo on the frontend which is what you’ve attempted already but you’ve received the error above. The only way as Phil mentioned previously is to create a separate app (using any programming language) on a server hosted by you to take the request via AJAX in BusinessCatalayst, send that request to Veeqo and then output the results. Also as part of this to avoid the error above you’ll need to expose the BusinessCatalyst URL in the Access-Control-Allow-Origin header. So you can pass for example this in the header from your custom app server:
This will allow BusinessCatalyst to access that resource on your server without such problems. Also this is much more secure and gives you more control because if you were making the request directly from the content area of BusinessCatalyst to Veeqo, you would need to expose your API in the request headers meaning that any visitor would be able to see them which you should absolutely never do.
In regards to your questions:
Do you think Veeqo devs will come to implement OAuth in the future?
We’re working on OAuth 2.0 authentication right now, it’s getting there and we’re just performing finishing touches. We’ll need to perform some tests on it first and begin by integrating it with internal apps first, then we’ll notify developers when it’s ready for public release.
Does it mean that Veeqo is currently vulnerable to hack attack?
Absolutely not. API keys aren’t too common these days due to how prone they are to being released accidentally (for example in version control, or in public API requests) so this is why we always recommend to keep them stored securely so that only you/your application has access to them on the sever side - nobody else should know it. This is why we’re introducing alternative authentication methods for API requests.
