I am a nodejs developer. My server should ask every x ms and retrieve new orders. Notifications will be sent by the client part of the service to the seller. I need some fields of the order, I use the order api for most fields, the report api to retrieve the telephone number, which is not retrieved by the order api.
What I need now is the list of all the products of the seller, with the properties: SKU, weight
What api should I better use?
I also want to confirm the order shipment by sending to Amazon also a tracking code, but I did not fine this in the apis. Is there this feature?
What I do is periodically download orders into my own system using the reports API. I have the complete order with header information including all SKU's on the order. The Orders API is subject to throttling which may affect you.
To update Amazon that your order has shipped and to send a tracking number, you will use the Feeds API. Look at the Feed Types, specifically:
_POST_ORDER_FULFILLMENT_DATA_
In the link above, there is a flowchart explaining the process.
Related
We are a using a micro-service based pattern for our project where we have Users and their Orders. Users personal information (name, email, mobile) is stored in User table in relational database while we are storing Orders data of users in Orders collection in NoSql database. We want to develop an API to get a paginated list of all the orders placed with order details along with finer details of user associated like - user name, mobile, email along with each order. We are storing userId in Orders collection.
The problem is how do we get User details for each order in this list since both the resources are in different databases. We also thought of storing user name, email and mobile in Orders collection only but what if a user updates their profile, the Orders collection will have stale user data.
What is the best approach to address this issue?
You can use API gateway pattern, UI will call to API gateway endpoint and the Endpoint will call the both the API/services to get the result and aggregate it then returns aggregated response to the UI (caller)
https://microservices.io/patterns/apigateway.html
Well it mostly depends on scalability needs in terms of data size and number of requests. You may go with the API gateway if you don't have too much data and you don't get many requests to that service.
Otherwise if you really need something scalable then you should implement your own thought with an event based communication.
I already provided an answer for a similar situation you can take a look
https://stackoverflow.com/a/63957775/3719412
You have two services Orders and Users. You are requesting Orders service to get all Orders. It will return a response data which will contains ID of Users (each Order contains ID of User). Then, you will make a request to a Users service to get an information regarding User by ID which you got before. And finally, you can aggregate those results (if it is needed).
As guys mention, good solution will be to implement API Gateway here. As a client, you will send a request to a single port with endpoint (to a Gateway) and Gateway should create logic which I have described before.
We are trying to figure out how to detect which Orders have at least one item returned and which items are returned in the order AFTER order has been shipped. We are using the latest version of MWS Orders API (2013-09-01).
Looks like the Orders API is limited, so is there another API that we can use for this?
I am importing customers from Amazon to do an integration with our ordering system and want to avoid having duplicate customers as we do a high volume of sales on Amazon.
Is there any report, or API that will allow me to get a unique customer identifier that will never change for that customer no matter how many orders are placed?
I have thought of the anonymous email that Amazon makes available, however I am unsure if this changes, or if it is a static value as it is not referenced within the API documentation.
Has anyone else found a solution for this, or have any suggestion?
the key is buyer-email and is available from order reports or from amazon fulfilled shipments data report.
The amazon fulfilled shipments data report will not contain buyer email information in certain circumstances, however the order reports will always contain the buyer email.
Amazon's FAQ documentation states:
Are there separate e-mail addresses per thread? No. The anonymised e-mail alias remains the same for all contacts that you have with each individual buyer. Use the buyer's anonymised e-mail address as a unique identifier to follow conversations across multiple orders.
I'm trying to automate the addition to and management of our products on Amazon. Looking at the API documentation for the MWS API it doesn't look like there's a way to determine if a product has already been added to Amazon by another seller and if so what its attributes are.
We are building a new product database for all the products we sell and have a table specifically for Amazon attribute data fields (ASIN, etc.). If Product information is already on Amazon, we'd like to pull that data via API and store it to our own database as well.
If you attempt to add a product via CSV and that product already exists on Amazon (and your attributes are in any way different ("m" != "medium") you'll receive and error. In that case you can just piggy back that existing product information and just upload a CSV with your price and quantity for a particular ASIN/SKU/UPC. We'd like to do away with uploading CSV files and again, have our own product table for Amazon attributes.
Will I need to also leverage Amazon's Product Advertising API to determine this or can it be done via MWS?
The documentation for Amazon's APIs aren't exactly fantastic and it's been slow going trying to sort through it all.
We're working with Ruby.
Amazon's Merchant Web Services API is limited to your Merchant account. So the answer to your question is that yes you will need to use Amazon's Product Advertising API to get information about products that aren't already listed.
That being said you should be aware that there are new restrictions being placed on the Product Advertising API that will limit the number of calls that you can make on a daily basis to 2,000. In addition to this you will have to get an Associate ID that will be tied to your account and needs to be sent with any request.
Also, I find that the information collected using the Product Advertising API is sometimes out of sync with the site and have resorted to scraping the info from the site itself. This has more overhead but you can be assured that the data is current. Of course this is only useful if you already have an ASIN or are dealing strictly with books (which use the ISBN as an ASIN) or Music CDs (which I believe use the UPC as an ASIN).
The MWS Products API is where you will find this functionality. Specifically the GetMatchingProductForId operation.
http://docs.developer.amazonservices.com/en_US/products/Products_GetMatchingProductForId.html
(This API probably wasn't available at the time of the original question)
I have a website and I would like to implement a paid subscription service. Its a simple service with only 2 types of plans. For now, ill just use Paypal. But im a little lost before start, mainly with the data model.
My main question for now is, what information do I need to keep for each subscription? Do I need to implement a shopping cart for this (dont think so)? Im not asking for a detailed explanation, just a few lights or resources to find a way to start. Thanks.
Depends on what technology you're using. Basic payments work a bit like this
-> You send them to paypal with a plan (you define the plan on paypal)
they know which amount to charge
you can pass custom parameters which they will pass back
Customer fills in application
<- paypal tells you that your predefined plan got purchased
in this same request, they send a lot of info about the payment including a GUID and your params
-> you ask paypal "hey, some one just told me this plan GUID got purchased, can you confirm"
<- paypal service returns 'yes'
-> you take the customer's ID from the params that you attached when you sent them to the paypal service and update them to "paid" in the database, or whatever
That's it in a nutshell...
Look at any subscription card mailer from any magazine and you can get an idea of what kind of data you will have to record. Start and end date for the subscription would be a good thing to keep, and what kind of plan the user is subscribed to. Once you have the end date, you just need to run a query to get the records of the users that have access. Something like
Select * from users where subscription_end_date is >= today
I'm sure there will be a lot of other columns that will go into your final product, but that will be up to you to decide what data you want to keep. What are the different states that a subscription can be in? Can someone be subscribed to both services at the same time?
PayPal does a decent job if you want to charge the same amount every month. However, if you anticipate your users making changes to their subscription plans (upgrades/downgrades) or needing to provide credits to their account for customer support purposes, PayPal would require that you cancel the subscription...and then have the customer re-subscribe.
[Full disclosure - I am a co-founder of Recurly.com]
Recurly handles the upgrades and downgrades, and provides automated customer emails to be sent out to your customers (on your behalf) for every event confirmation, and invoice that occurs. You also have a full account management dashboard and reporting so that you don't need to build this yourself.
Best of all, if you ever decide to leave PayPal, and move your business to a standalone payment gateway, Recurly stores all of your credit cards in a PCI compliant vault so you don't need to ask you customers to come back and re-subscribe. (PayPal will not return your customer credit card information). You simply configure your new gateway in Recurly, and payments will be processed without any interruption to your business.
Here is a blog post we wrote on the topic:
http://blog.recurly.com/2010/08/top-ten-reasons-to-use-recurly-vs-paypal-for-recurring-billing/
-Best of luck.
-Dan