We have a series of products that are subscription based. ie: first 7 days free, then a monthly or annual fee with a start date and finish date. Is this possible ? and could we drive this through the REST API ?
Moving my comment to answer -
I would like to second #KimballRobinson's comments. It might be possible. The REST API by itself gives you access to store data. You can create products and maintain them. In your case, things to consider - what is the product taxonomy like and can it be defined as custom fields or something of that sort. Maybe you can set it up in a way such that you charge/invoice the customer for the same product every month or annually. There are ways in which you can implement subscription. If you define details more on the scope of what you are trying to accomplish, it will be easier to figure out
Related
I have thousands of items and multiple eBay accounts.
They are mostly variation items with differing prices per color and size variation.
What's the best way to bulk list all the items?
Previously, I had everything listed one at a time, using either the addItem or addVariationItem calls.
But that can't be how large sellers manage things if in my situation.
What is the preferred way, the eBay API of choice, that best accomplishes this task?
Likewise, for updating the price and stock for all SKUs multiple times per day?
Is there a one-shot call or upload way which can do this?
There are some Bulky options with eBay APIs, but if you need to make more than 5000 calls per day you need first to build an App and pass eBay verification, and since 1 item means at least 1 call...
Elsewhere you have to use some SaaS services.
If you've already passed such step you can search for what was the LMS services. Actually they've been decommissioned last weekend but there is the new version (that's not working properly but we hope it will do soon). I suggest you to follow the migration procedure. It is not very clear, as all the eBay documentation, but IMHO is the best path.
I have designed some API which have some nested resources and I am wondering how to reduce the number of POSTS when I am creating some records.
for example, I have the following resources:
/orders/
and
/orders/{order_id}/products/
at the moment I need to run two POST separately if I need to create a new order or a new order's product but I would like to reduce the time for this and run only one POST.
Is this possible? is there any documentation I can read about this?
Thank you
Although you might have found your answer in an other thread there is still some issue regarding your endpoint design.
The first intuition that your endpoint give is that product resource could exist in several place.
./orders/{order_id}/products/{prod_id}
./products/{prod_id}
The question you should ask yourself is: Do you really want to refer to product?
Can product be leaving outside of any orders?
Having a resource sitting in 2 different place might not be that great as you are managing 2 different endpoint with similar behavior. Keeping consistency between both endpoint is not that easy.
My 2 cent is to avoid the term product as it can be confused with a single instance of a product. For example if you sell a toothbrush branded AAA, sku 1234 an order is not compose by this product but by one off the item that you have in stock. The item is "instance" of the toothbrush branded AAA, sku 1234.
As I understand your question you are not really referring to a product but more to a stock-item which should be a unique id.
The resource stock-item if you decide to have one should exist prior to the order. I guess the customer is not adding item to your stock and at the same time purchasing this item.
In conclusion I think that you are not creating the stock-item resource at all when creating orders but just making a reference to it.
A client of mine has a service-oriented ecommerce site on Shopify and he's asked me to assist in making a few changes. I've never utilized the service so I'm not really familiar with it.
The price list was static at first since the client used the same vendor however now that they're growing - and therefore using multiple vendors - the costs are fluctuating and therefore the prices on Shopify need to reflect that.
I need to set it up so that when a customer logs on a vendor is programmatically chosen based on their geographic location and the prices (shown to the customer) adjust accordingly.
Is this possible? And if so, what objects/API docs should I be looking at. I seems as if I can easily hard code this with IF statements but I'd like this to scale cleanly so I'm looking for a more efficient solution.
I think this should be possible. Based on your comment:
Will I not have a zip code for the customer? – RyanMac
The easiest way would be to create a Product Variant for each region. Based on the customer.default_address you could find the customers ZIP code. Next step would be to use this within the product.liquid template to select the correct variant.
The biggest problem you have is determining their location. When a customer logs in, you know who they are, so you could dish out only products of interest to them. Problem is, how do you lump people into those regions? You have your work cut out there. When you create a customer you can assign them any code you want, so perhaps you could just match customers to vendors using a match on that. Lump any customers into GroupA and you show only products with Vendor GroupA, any customers assigned to GroupB render products from vendor GroupB....etc
Is there a way to query the API to find a Shop's orders with more detailed query parameters? For example I would like to be able to find an order by entering the client's name or the date of the order.
The available URL query parameters don't allow anything like that.
I realize I could just request all the orders and then filter that data, but I would rather do it directly in the API instead of locally to avoid any overhead.
Edit: Actually I just realized that the only way to query for a specific order is to enter its internally used order ID that the shop owner has no knowledge of. It would be really neat if I could query the API instead by the order "name" which is shown as the order's ID to the shop owner and the order recipient. Any ideas?
I look at it like this. Let's say you're poor and cannot afford a data store for orders in your App, but you have API access and you want to provide a search for merchants.
You get 250 orders per call and 500 API calls with zero troubles, so that is 125,000 orders. The API provides you with 125,000 objects that you are free to query any way you want. Want to show the merchant just orders with last name Smith and a line item of dingo balls with a chaser of a cart note set to "no saturday delivery please"... you can do that. Has nothing to do with Shopify, just your code. I think it is pretty easy to query orders for anything of interest, your mileage may vary.
Me, I keep interesting aspects of orders in a data store in my Apps, and then provide merchants with search results that way... cuts down on API calls, and keeps interesting facets closer at hand.
I've been researching eCommerce payment gateways and service offerings, but I'm an eCommerce novice, so please excuse my ignorance.
I wish to set up an eCommerce solution with the following requirements:
User "subscribes" to the service on a yearly basis. This service includes a single product subscription for a set amount (let's say $50/yr).
User can "subscribe" to additional product services for a lesser rate per year (let's say $25/yr).
I will need to store a product service unique Id of some sort for each product subscription the user subscribes to in order to show them product unique information. I also need to prevent duplicates...for example, user can subscribe to product ABC and XYZ, but not 2 of ABC.
Is PayPal the best solution for something like this? Is there a better solution? Any assistance is greatly appreciated, even if just links to specific tutorials or examples.
Update: It looks like Chargify could be the perfect solution.
You can also use Authorize.Net's CIM solution which, based on what I read at the chargify website, does most of what chargify does except your customers never need to leave your website. The Customer Information Manager allows you to create profiles for your members. These profiles store sensitive information like credit card numbers and billing information so you don't have to worry about PCI compliance or hackers stealing your information. You then can schedule a cron job to charge them monthly for whatever amount they owe based on their current subscription. Since you control when the payments happen it also allows you to charge them pro-rated amounts for subscription changes mid-month.
[link text][1] seems to be the best solution for me. I still need a merchant account, but this takes a lot of the headache out of handling the subscriptions.
[1]: http://chargify.com Chargify