How to set up mws for a developer account


I have an Amazon professional seller account.
I have an employee who has an account under my account. My employee
doesn’t have all the permissions activated yet.
How do I set it up mws so he can have access to the API and develop an app just for me?
He will use it in his account and not my account.

I hope my question is clear.


The issue is that there is only one set of MWS credentials per pro seller account. They have also become ridiculously hard to change, so rotation is a problem without risk of disruption. The sub-accounts you are creating are for the seller central access.

The bottom line is that unless your developer is a highly trusted long term employee, they shouldn’t have direct access to your (horribly) semi-permanent MWS backend credentials. Even if they are trustworthy, they risk accidentally exposing the keys in code or dev environment, and still require reasonable controls for protecting data generated during development or testing. Having the keys means control over execution and data generated.

If your development is secured well in the cloud, you can setup a signing function that your developer can call but can’t modify, and you can then secure the credentials separately. (such as AWS secrets manager) That way you can control who/what can call the signing function, and block access when necessary.


Your computing environment needs to meet Amazon’s Data Protection Policy here:

Then you need to submit an application under the primary account to obtain a Developer ID. If your Developer ID is approved, you will receive the needed credentials in order to access the API. Your developer can then use the credentials to create the application just for you.

The security settings in the seller account do not apply to the MWS Developer ID. The data and API calls available to your Developer ID are controlled by Amazon and are based on your answers to the questions in the Developer ID application.

From my point of view, trust is needed, but length of employment is Irrelevant. What matters is the developer has the skills needed to do the job well.

David Nelson
Dynamic Enterprise Technologies Inc
Seattle Washington USA


“Technology trust is a good thing, but control is a better one.”
― Stephane Nappo

To be a bit more clear about the detail above, giving out long-term credentials to a temp or short-term employee is not good security practice. Development environment needs to be controlled as per the DPP.

No legitimate consultant or developer should be asking for or giving out MWS developer keys after the last set of rule/access changes. It is a direct violation of the developer AUP

Keep data secure
Account access

  1. Never share keys or passwords.
  2. Never ask for or accept a Seller’s Secret Keys for any purpose.
  3. Only act on behalf of Sellers that have granted you permission through third-party authorization.


You are incorrect. The bad security practice is not related to how long a company keeps their staff. The actual bad security practice is what you are referring to as "long-term credentials". There should be no such thing in a secure organization. First, companies should be changing their passwords on some regular basis (like every 6 months). And second, if a staff member knows a password and leaves the company, regardless if the person was there for 10 days or 10 years, the password should be changed ASAP after the person leaves the company.

You have misapplied the rules to the question that started this thread. The rules you quote are talking about company X giving their credentials to company Y. That is not what we are are talking about here.

The question that started this thread is about company X, where staff member A (like President of company X) gives the credentials to staff member B (developer at company X). This is not a violation of the rules. The rule that applies to the sharing of information within company X is the "Least Privilege Principle" which means within company X, you provide information only on a "need-to-know" basis.

David Nelson
Dynamic Enterprise Technologies Inc
Seattle Washington USA


The entire point has gone over your head. The MWS credentials cannot be easily rotated.


I understand the point you were trying to make. I just don’t agree with it. You can easily open a case with Amazon to request your secret key be changed. Then as soon as your old credentials fail, you can lookup your new secret key, plug it in, and be on your way. If you are in a big hurry because of a security concern, you can also email your concern to

David Nelson
Dynamic Enterprise Technologies Inc
Seattle Washington USA


True key rotation means there is an overlap between the old keys getting shutdown and the new keys working. Amazon has no mechanism for this, they cancel the working keys, and issue new ones.

For those of us who depend on the credentials in a production environment, this is a guaranteed service interruption. Worse, it is impossible to plan for since no one has any idea how long it will take MWS support to act on the case. There have also been reports of extended outages before new keys are issued. This used to be fairly quick procedure, but it changed when the credential clampdown started.

Reporting it as a security incident to security@ should certainly speed up cancelling current keys. I have my doubts it will speed up getting new ones, but let us know when you try it. Most of us try to avoid security incidents, but to each their own.


I am in the process of registration for Amazon mws and the questions on security are a bit confusing.
question: do you restrict access to amazon mws data based on users job duties? yes or no.

I don’t have amazon mws to begin with. why would they ask me such a question when I am trying to register for amazon mws? It makes no sense.


Because they want to know how you will secure the data you obtain from MWS especially when it comes to PII. Change the ‘do you’ in the question to ‘will you’ and select your answer.


They should change it. Its misleading


Or, have it as an either or depending on “usage.”


I think the wording was originally setup as it is because many already had MWS API access and Amazon was checking with existing developers to see if their current software and environment matched the rules.

In the case of a new software on the drawing board, I recommend that planned software along with it’s planned environment should meet the requirements on paper first. Then when you are asked questions like “do you” or “how do you”, you can answer according to your plan.

If you don’t have a plan yet, I would recommend creating a plan first with enough detail so you have all of the issues in the DPP and the AUP covered. Then you will be better prepared to answer the questions.

David Nelson
Dynamic Enterprise Technologies Inc
Seattle Washington USA


That is not going to work because the “Developer Registration and Assessment” form gives you the options to select only “Yes” or “No” for that question and there is no place for an explanation. :slight_smile:

The “Access Management” section of the DPP explains the requirements in this area.

David Nelson
Dynamic Enterprise Technologies Inc
Seattle Washington USA


It would work just fine if Amazon set it up that way, which is what I am talking about. The form should be set up to accommodate both types of applicants.