I have a mobile app that allows people to upload information of clothes they have and share it with their friends. I have good traction - increasingly more users every day.
I want to create a new feature that allows users to sell unwanted items on eBay. Ideally, they'll click a button and the item will be available for sale on eBay.
I went through the developer APIs and I'm not even sure where to start. I can't tell whether I should try Retail-Standard Selling (New Sell APIs) or Traditional eBay Selling (Trading APIs) or even something else. Please could someone point me in the right direction?
Since we're speaking of unique items I would suggest to use "old" trading API AddFixedPriceItem
that's made for garage-sale and can do everything with just one call. (1)
while new Sell APIs are meant for stores selling new items in multiple quantities
and requires several calls to achieve the same result (create depo, images, listing, offer...)
BUT
despite what eBay writes (that will continue to support Trading APIs)
we see that every month some Trading APIs are decommissioned or deprecated:
for example last January they removed GetCategorySpecifics
and for next April there will be others..
Clearly you could mix the APIs, using the best combination of both
but since you're at beginning and since the 2 API family are completely different, I suggest you to use new Sell APIs
(1) Just to create the Listing, then several other are required to find proper category, itemsSpecifics, creating the profiles.... and so on..
Related
I am trying to play around with FedEx APIs: https://developer.fedex.com/api/en-us/home.html
and actually I would like to know, is it possible to track new created Shipment via Ship API on sandbox/test environment?
Actually I've tried to create multiple different types of Shipments validate them, and received 200 Ok response, however I wasn't able to track it by tracking number returned in response, so the question is it possible at all on API sandbox environment to create Shipment and find it by tracking number on FedEx site or using Track API's Track by Number Endpoint.
Cannot find such limitations in documentation, so will be very appreciated if someone can shed light on this.
I think it's not possible to track with the tracking IDs which you get from ship API.
But you can track the orders with the mock tracking numbers from here.
It's really very irritating because when we get the tracking IDs in the test environment, we should be able to track the orders by using them in the test environment. FedEx should have to focus on this.
I would like to build an app that shows me the price history of products and notifies me when the price reaches a certain limit.
I know that some of these things already exist, but I'm also interested in learning how to build them and trying out some technologies.
This is my question:
how do I get access to the Amazon Product API without having a website?
Right now, there are two Amazon APIs:
The older one is called Amazon MWS. You find its documentation here.
The newer one is called SP-API (abbreviation for Selling Partner API). This is their main page.
The access to both is only possible after registering as a professional seller (sic!), which costs a monthly fee (about USD 40). After registering as a seller, you then have to additionally register as a developer within your seller account.
If you do not want to pay monthly fees or register, you could also try webscraping their website. Here I do not now, what their policy is.
I'm looking for a way to allow our clients to do recurring payments to discount these payments based on the credit in their account which can be earned or deposited in many ways. For example, if they need to pay $20 and have $5 in credit, I would like to only bill the remaining $15 automatically without any need for additional website visits.
Looking at the documentation for PayPal's REST APIs, I don't see any clear way to do this. Is the only way to do this to send them a refund automatically? Or is there a way to get approved to bill clients up to X amount per month but allow us to bill under that amount. I thought billing agreements would allow for this, but after reading the documentation, I'm unable to figure out a way to do it. If it's possible, could someone walk me through what API calls would be needed to do this?
Thanks for any help you can offer.
There are a couple of different ways you could do this sort of thing, but I would avoid the REST API for now. It's still too new and doesn't provide as much functionality and features as the classic API.
Within the classic API, you can use either use Preapproved Payments, which consists of Preapproval and Pay APIs, or you could just use Express Checkout and/or Payments Pro with Reference Transactions.
Either way you'd basically be building your own recurring payments system where you'd setup a billing agreement and then your app would trigger the variable amount payments accordingly.
I'm kind of new with the eBay API. I found two methods to get item information:
Trading API has GetItem method
Shopping API has GetSingleItem method
So, what is the main difference between these two APIs?
I need to search items in eBay through my website, I'm making it with the findingItemsAdvance. I also need to get the weight and item dimensions in order to calculate the right price, but the findingItems doesn't provide it.
The eBay's team advice is use the Trading API, but I don't understand the main difference between the two APIs. Thank you.
This is a two part question. Part 1 is, what is the difference between the two calls. Part 2 is, what is the difference between the Trading and Shopping API.
Lets start with Part 2 first.
The Trading API is the "full featured" API. It can do just about everything you would want to do with eBay. Because the Trading API can do everything, it is longer, and to an extent, more unwieldy. (Edit: The trading API can't do everything, it is limited to your user only)
The Shopping API is not your general purpose eBay toolkit. It is focused, it provides Shopping related functionality and that is it. Thus the calls are generally simpler and easier to work with.
Moving back to Part 1, we can see an excellent example of this.
The Trading API's getItem call has a output listing that clocks in at 739 lines.
The Shopping API's getSingleItem call has an output listing that clocks in at 242 lines.
This is an example of the increased strength and complexity that the Trading API offers. The Trading API is the better all around choice, while the Shopping API is good for well, a "Shopping" related app.
I'm looking into building a web app that allows multiple e-commerce stores to coexist on the same installation and lets allows each individual vendor manage their own products, pricing, sales reports, etc. I know that there have been a number of previous questions on the Stack regarding the best shopping cart software, but this is a bit of an unusual twist and I couldn't find it answered elsewhere.
Obviously, open source is better from a pricing standpoint, but I've got no problem with spending money on a quality product that meets my needs. The ideal package would allow each store to be uniquely skinned, would minimize the amount of time that it takes to get a new store up and running, and would include payment gateway and shipping integration.
I've run across a few things in my scouring of the web, but haven't found "the one" yet--I know that osCommerce sort of supports what I'm trying to do, but I'm looking for something designed with this functionality in mind. Any ideas?
Thanks!
Justin
I am at present looking into the same thing. After looking at all the different cart on the market I have settled on PHP Mall 2. I have had demos of X-Cart Pro, iscripts multicart and a few others.
There were only 2 that were any good at handling payments direct from buyer to seller without any added costs of have a mod done for that. They were PHP Mall 2 and iScripts Multi cart. iScripts Multicart didn't really have alot happening in the backend, and vendor shops were really just an about us page with their products showing.
I settled for PHP Mall 2 becuase each vendor can have their own website as such and can customise it to the way they want it. They can choose from a number of templates for their shop.
The part I really like about it is the payments system, there are a number of payment gateways out of the box and the vendor can choose which ever he/she wants. (because not everyone use paypal right!). Its also a fair bit cheaper than all the others and provides alot more from a site admin and seller admin side of things.
I was tasked with looking into a multi vendor cart for a project that was canceled. Before it got canceled, I felt that the below were strong contenders. This is not a comprehensive list but it's somewhere to start. The requirement for multi vendor was paramount, so the listed have varying amounts of CMS/blogging etc; so they are not necessarily apples to apples.
I did get to try out magento community and using information found here http://www.magentocommerce.com/boards/viewthread/145/ got what I felt was the correct experience for multi store/vendor for my purposes. Mileage may vary depending on requirements. It's a beast though and for some reason comparison doesn't indicate the multi vendor capabilities. My impression was that Magento was definitely for the technically minded, with a very high degree of configurability available. It's a meta system for sure. The average joe business owner wouldn't stand a chance with it. However, it might be a perfect for resellers.
http://www.x-cart.com/mall_solution.html
http://www.php-shop-system.com/products/iq-cart-for-joomla-our-new-cart-component-for-joomla.html
http://www.magentocommerce.com/product/compare
I am also in search of a multi-store solution. Magento Commerce is too expensive. OpenCart now supports multi-shop but only a single user can manage the stores. I would have preferred setting up multiple stores and have different users manage each store.
I've also been undertaking research within this area and discovered the following options;
For joomla = http://www.ijoobi.com, IXXO
For Magento = http://www.unirgy.com, MVDE
There is also an interesting product called MultiCart from iScripts, and the X-Cart Pro from Qualiteam.