Get your public SP-API app approved, with OAuth working, in one week.

Probably not. Draft is the state every new app is created in, not a review queue. Amazon reviews your developer profile and approves or denies that, but the app stays in Draft until you list it in the Selling Partner Appstore, and listing is what changes its state to Published. A Draft app still works: sellers can authorize it through your website as long as the authorization URI carries version=beta. If you did submit a listing and it's back in Draft, read the case log. Amazon's listing statuses define Draft as “Your listing is saved or rejected.”

On the app, not the developer profile: Edit App in the Solution Provider Portal or Seller Central, in the OAuth Login URI and OAuth Redirect URI fields. Public apps need both, and the redirect field won't take a localhost URI. The order is what trips people up. The seller consents in Seller Central first. Amazon then sends them to your Login URI with amazon_callback_uri, amazon_state and selling_partner_id so you can link the account, and you send them back to amazon_callback_uri with amazon_state and your own state. Only then does Amazon call your Redirect URI with spapi_oauth_code. Exchange that code straight away, because it expires after five minutes.

Your app is in Draft and the authorization URI doesn't say so. Amazon's description: “This error occurs when you authorize an SP-API application in Draft state through the OAuth production workflow.” Add version=beta to the authorization URI while the app is in Draft, and take it out once the app is Published. The related codes: MD5101 means the redirect URI you sent isn't one registered on the app, MD5110 means it contains a # fragment, MD9100 means the app has no Login URI and Redirect URI, SPDC8143 means the seller signed in as a non-primary user, and CONSENT_LIMIT_REACHED means you've used up your authorizations.

From your own system, in your own words. The Security Controls section asks about your security practices and expects them to match the Acceptable Use Policy, the Data Protection Policy and the Solution Provider Portal Agreement. Amazon wants it answered by “the tech team responsible for data security”, with each free-form answer under 500 characters. The dead end is pasting the policy back at Amazon (its registration guide says “Do not copy information from the AUP, DPP, or other Amazon policies”) or describing controls you don't run. The Data Protection Policy gives Amazon the right to audit the systems behind your app, so an answer you can't back up works against you.

For all Amazon data: encryption in transit with TLS 1.2 or higher, a unique ID and MFA for every user, no shared accounts, least privilege, access reviews at least quarterly, an incident response plan reviewed every six months, notice to security@amazon.com within 24 hours of detecting an incident, and deletion within 30 days of a seller revoking your access. If you hold buyer PII, a stricter section applies to the whole data store it sits in: encryption at rest (AES-128 or RSA-2048 at minimum), PII kept no longer than 30 days after order delivery unless the law requires it, logs kept for 12 months with no PII in them, vulnerability scans every 30 days and a penetration test every 365. That's the policy as published in October 2026.

Start with Amazon's own pointer: a denied registration links to the questions and controls that were missed, and you fix those and resubmit the profile. Beyond that, the causes you can check yourself are written into Amazon's rules. They include a website that's login-only, under construction, or missing pricing, a direct contact method or a privacy policy. A use case the Acceptable Use Policy rules out will do it too, such as using buyer PII for anything other than merchant-fulfilled shipping or legal and tax requirements, or aggregating data across sellers to provide or sell to others. So will asking sellers for their Seller Central passwords or access keys, security answers copied from the policies, or a follow-up question left unanswered for five days, which closes the case and leaves your access unchanged.

Amazon doesn't publish a turnaround time on its registration pages, so I won't invent one. My part is fixed at one week, but Amazon's review runs on its own clock. Two things add time, and both are in Amazon's documentation. Restricted roles bring an architecture review with Amazon's SP-API Solutions Architecture team, which can include a screen-share demo. And any follow-up question gives you five days to answer before the case is closed. That second one is the delay entirely in your control.

Amazon's public developer guide doesn't list incorporation as a requirement. The profile asks for an organization name, a website, a country and a primary contact, and the Acceptable Use Policy defines a service provider as “an individual or entity”. What Amazon does check is that you present as a real business. Your website has to be public, describe the services your app offers Amazon sellers, and show your company name, app name and logo, your pricing and a direct contact method. If you ask for restricted roles, the first phase of that review is called “Business verification review and developer profile assessment”, and it looks for complete business contact details, a privacy policy and terms of service.

Not to get started. An unlisted public app can be authorized through your own website by up to 25 sellers (vendors are unlimited), plus 10 self-authorizations. Past that, Amazon returns CONSENT_LIMIT_REACHED. Listing is what moves the app from Draft to Published and removes the seller cap. Amazon's registration guide also says public developers must list their app, so if you're building for more than 25 sellers, plan for it. Either way, public apps need every seller to re-authorize annually, so store each token's age and prompt sellers when the year is up.

Only if a feature can't work without buyer data, and only for uses Amazon allows. The Acceptable Use Policy limits buyer PII to merchant-fulfilled shipping or legal requirements, including tax. Restricted roles bring more review: an architecture review and a data security assessment of how PII moves through your system. And once PII sits in a data store, the PII section of the Data Protection Policy applies to that entire store. If your features run on orders, inventory and fees, leaving PII out keeps the approval simpler.

No. That session is for sellers, brands and agencies getting API access to their own accounts. This is for software that other sellers authorize over OAuth, which Amazon reviews as a public developer. The registration, the policy obligations and the authorization flow are all different, and none of it fits in 45 minutes.