Direct Seller Integration/Usage

[A-Lawrence]

Hello.

As a seller who integrates directly with the MWS API (no third parties use our software), why is there not a much better route for our usage? In the old MWS API we had a client secret that we could use, without all the added overhead of IAM policies etc.

This feels like an area that's been overlooked...

[charliecode]

Hello @A-Lawrence. The new SP-API is def quite a bit more work than the old MWS API. However, the old MWS API was inherently insecure. Granted very few developers are security experts, which makes the switch to the SP-API all that more difficult. I see this as a very good thing. Most websites on the internet are not secure and easily hackable. Amazon is doing all they can to force proper security practices while making it as easy as possible for devs to learn and implement them. Of course this is going to be frustrating at first, but once properly learned it will be a good thing in the long run. In the event you weren't aware, there is the Self Authorization which should meet your use case. Good luck.

[A-Lawrence]

@charliecode thanks for taking the time to reply. All of that is great, but I stand my ground on us being overlooked.

With reference to their migration guide we can't have a hybrid application unless we publish our app.

So, how do sellers currently using MWS API, migrate? I'm not willing to (a) have some kind of big-bang migration; (b) set up a separate (paid for) developer account and risk us being suspended for having multiple accounts (which we will be).

[charliecode]

@A-Lawrence I can't speak as to what others are doing. I do know quite a few have spoken on here about using the hybrid approach. For my part, I decided to use the SP-API and left MWS completely out of it. I 110% agree with you on the necessity to create a "paid for" developer account. You're not the only one who feels this way as is stated in amzn/selling-partner-api-models#386 as well as other issues. Amazon has definitely missed the mark on this one. Having said that I don't think it's necessary to have two accounts, although if you find it is in your use case I know a former client I consulted for contacted Amazon about this and was told it was perfectly fine to create a new Selling on Amazon account for development purposes only, so far as you don't actually sell through it, in the event you already have another Selling on Amazon account you are selling on. If you decide to go that route I would recommend contacting them directly so it's on record.

[A-Lawrence]

@charliecode with all due respect, having to deal with seller support on a daily basis, I don't trust a word they say so I wouldn't be looking to do that. There are countless scenarios where people get their accounts suspended for being duplicated - the route to becoming activate again is long and arduous. I can't risk doing that to the family business, in the middle of a pandemic. So until we're forced to, we're staying with MWS API (note: we don't have the September 30th deadline, as we aren't a 3rd party provider). MWS works fine, I was only going to upgrade because I know it's the right thing to do, but not at the cost of countless hours of my time.

In order to upgrade, I'd want a rock-solid assurance that (a) we can run a hybrid application without publishing it, (b) our existing MWS implementation won't be affected; (c) that if I have to setup a separate developer selling account, our main one won't be suspended. None of those assurances are coming from seller support. They can't even explain to me why parts of the catalog don't work, or why there is incorrect data on some of our dashboards. I'm not putting our income at risk.

Also, to come back on your points about (i) MWS being insecure; (ii) developers not being security experts; (iii) "Most websites on the internet are not secure and easily hackable". I'm fairly confident that what we've learnt over the years is that because developers do not know (either because they don't care to learn, or do not have time to) how to use AWS property, we end up with leaks and issues - a la all the public S3 buckets that we see constantly.

I avoid AWS as far as possible - in my day job I leave that to our DevOps experts, for the family business I've always kept it at arm's length. I have completed the IAMs setup as per the documentation, but I don't have the time or inclination to worry about what any of the spaceship-looking panel does, nor what I've actually setup. If they just said there was a route for MWS => SP-API migration, for self-authorization, with the need to refresh our tokens periodically, then I'm all over it. But this complexity for individuals interacting with their own accounts is beyond a joke.

[A-Lawrence]

P.s. My opinion from my other issue still remains. Interacting with Amazon's MWS/SP is the least developer-friendly experience out there. If an entire financial institution like Stripe can run on conventional authentication mechanisms and standard OAuth implementations (rather than Amazon's "version"), I don't see why Amazon cannot. Heck, even my own bank provides a better experience than this when writing applications for others to use to manage their finances.

[charliecode]

@A-Lawrence Amazon has recognized the issues with their support and are actively making improvements, I've been around since before this API was launched and can testify to that fact. They still have things to work on, no doubt, but I also don't doubt you'll find your concerns answered by them on this issue. You mentioned the difficulty of the pandemic, no doubt you can appreciate that this api was launched at the height of the pandemic. I can speak first hand to the sincerity and hard work of the Amazon team, which they’ve shown even while facing their own issues because of the change in work and living conditions.

I'm passionate about security and am definitely empathetic towards anyone learning how to make the AWS cloud secure. Problems with Amazon's documentation being difficult to learn is company wide, mainly because it's not new developer friendly, usually not because the info is not there. I've been engineering exclusively with AWS for the last 6 years or so and can certainly say there's a steep learning curve to learning how to use their documentation. Having said that, once you put the time in and learn it, a ton can be accomplished quite quickly.

You mention the type of person who either doesn’t care to learn or have the time to learn AWS. IMO those types of people have no place developing on AWS then, they can do so somewhere else. Really, they have no place being engineers, that’s the heart of what being an engineer entails, the desire and time to constantly learn. They also have no place developing on the SP-API, since Selling Partners and Amazon purchasers personal data should be handled with the upmost seriousness and protection. Whether it’s a third party application or not is null, as there’s always buyer data at risk of being exposed and absolutely any system can be broken into.

For me, it’s unfortunate you said these security practices are unnecessary and a joke. Although comments like that do make me feel better about Amazon’s need to make these practices mandatory. The comparison to Stripe or your personal bank are apples and oranges, the use cases are totally different. I understand you’re frustrated, I’ve been frustrated too while developing on this api. What I don’t understand or agree with are some of the points about security, Amazon would be taking a serious step backwards if they were to cave to them.

[A-Lawrence]

@charliecode > Amazon has recognized the issues with their support and are actively making improvements

We're digressing here, but having been working with the marketplace since 2012, I disagree. Just recently we've seen the closure of multiple email addresses, which now return a reply which states "Your email will not be reviewed", with no alternative. We've seen more frontline teams replaced with automation that gets it wrong on 90% of occasions. Seller support teams remain under-tooled for their roles, and restricted in how they can reply - often copying/pasting help articles and canned replies that ultimately don't make sense to the question asked. I don't believe for a second that sellers are valued in the way everyone thinks.

You mentioned the difficulty of the pandemic, no doubt you can appreciate that this api was launched at the height of the pandemic

That's their own choice though. As is the self-imposed deadline for migrating third-party users. I don't have sympathy for those self-imposed types of impacts at a company level, whilst at the same time I do sympathise with the team members who are also experiencing what the rest of the world are.

Problems with Amazon's documentation being difficult to learn is company wide, mainly because it's not new developer friendly, usually not because the info is not there.

This we can agree on.

You mention the type of person who either doesn’t care to learn or have the time to learn AWS. IMO those types of people have no place developing on AWS then, they can do so somewhere else.

But you're now conflating two points I've made. There was previously no requirement at all to engage with AWS as a marketplace seller (unless you wished to subscribe to notifications). I dislike AWS for all its complexities, and it's often my last resort in my professional projects. It's a time sink. However, to suggest that...

Really, they have no place being engineers, that’s the heart of what being an engineer entails, the desire and time to constantly learn.

Is a really disappointing reply. You've essentially said that if an engineer isn't willing to learn AWS then they shouldn't be an engineer. That's disingenuous and demonstrates an element of blind support for Amazon themselves. I know of many talented engineers who have absolutely no knowledge of or regard for AWS, and they never will.

They also have no place developing on the SP-API, since Selling Partners and Amazon purchasers personal data should be handled with the upmost seriousness and protection. Whether it’s a third party application or not is null, as there’s always buyer data at risk of being exposed and absolutely any system can be broken into.

Nobody is disagreeing here about whether or not personal data is something that should be respected and protected.

However, you've entirely missed the point I'm making. We will eventually be forced to migrate to the SP-API - I know that fact. However, to bundle individuals up into the same bracket as third party providers will lead to there being more potential for leakage. If you take an individual who doesn't really care for this kind of thing (i.e. someone who doesn't consider that customer's data is valuable and should be respected), you aren't fixing this by making the integration process more rigorous - they'll still jump through those hoops because the documentation tells them to. They won't suddenly start extending the same level of security practice to their own infrastructure though. That is the point I'm making about making this process overly complex - it's like spending your time trying to crack a nut with a rube goldberg machine in the hope that everyone will only ever crack nuts with it, only to find that there's a nut cracker in the cutlery drawer. It's then moot as to whether they should be developing on the SP-API because this process won't stop them from doing so, it'll just alienate developers who've had to expend their effort and energy into complying with these processes, rather than ensuring that their own internal tooling which consumes the data, is as robust as it could be.

As for my comparison to financial institutions, I can capture customer data on Stripe over an API with (in your eyes) less security. I can then repeatedly charge that customer's card - which the details were saved for. That's a fairly destructive action. Amazon doesn't extend anything nearly as high-impact as that to SP-API consumers.

P.s. Please don't think I'm berating you personally - this is just discourse about the developer experience being provided here.

[charliecode]

Good luck @A-Lawrence.

[seanevan]

Hi @A-Lawrence,

I wanted to chime in on this thread to let you know that the team here working on SP-API appreciates many of the concerns you've shared, and are working to address them. We greatly appreciate your direct feedback.

For example, we are very aware of the pain points around tying developers to Amazon seller accounts in terms of suspensions or other account actions that may impact developers' integrations adversely - in particular as we launch more features for Developers with SP-API. We're actively working on planned features to reduce developers' reliance on seller accounts. I know that longtime developers with MWS would have wished for this feature long ago - it's only with the release of SP-API that we're now able to address such concerns, and the team here is hard at work fixing such points of friction.

An answer one other specific point in your message above, you have my assurance that you can run a hybrid app without publishing it. If you open a support case and provide the ID here, we'll take a look to see where we can unblock you.

While I'm not at liberty to get into some of the other subjects raised on this thread, please know that I read every message, and your concerns are heard by the team here.

Best regards, Sean Evans Amazon -- Manager, Support Engineering

[github-actions[bot]]

This is a very old issue that is probably not getting as much attention as it deserves. We encourage you to check if this is still an issue after the latest release and if you find that this is still a problem, please feel free to open a new issue and make a reference to this one.