The seller consent screen
When a third-party app requests access to a seller's Amazon account, the flow goes through a consent screen hosted by Amazon, not by the app developer. There, the seller sees which data and permissions are being requested and has to click Confirm to grant access, or Cancel to deny it. This explicit consent is the heart of the model: no app gets access to the account without the seller's approval.
Public app vs. private app
Amazon has two authorization paths. A public app, distributed to many sellers like most commercial management platforms, must be authorized through the Selling Partner Appstore or an "Authorize" button on the developer's own website, following the full OAuth 2.0 flow via Login with Amazon. A private app, built by a seller or developer for their own use with no plan to distribute it, can be self-authorized directly in Solution Provider Portal, even while it is still in draft status, without ever publishing the app.
Authorization code and token exchange
After the seller confirms, the app receives an authorization code
through its configured redirect URI. That code alone grants access to nothing. The app
has to exchange it for real tokens with a POST call to
api.amazon.com/auth/o2/token using
grant_type=authorization_code, the code it received, the
redirect_uri, and the app's client_id and
client_secret. The response contains the access token (used for API calls)
and the refresh token.
Refresh token: why the app doesn't ask you to log in all the time
The refresh token is stored by the app and stays valid long term. It is
what keeps the seller from having to log in again for every API call. At runtime, the app
exchanges the refresh token for a new access token with a
grant_type=refresh_token call (plus client_id and
client_secret). The returned access token expires in 3,600 seconds
(1 hour), the same lifetime used by both the SP-API and the Amazon Ads API.
What this means for sellers in practice
In practice, the seller goes through the consent screen only once, when connecting the app. After that, the refresh token keeps access working without interruption until the seller revokes the authorization, which they can do at any time to cut off the app's access immediately. None of this changes between public and private apps: the difference is only in how the app reached authorization, not in how access is maintained afterward.
How EcomVision helps
EcomVision follows this same OAuth authorization model via Login with Amazon to connect a customer's account. It never asks for or stores your Amazon password, and token renewal happens in the background, so syncing of orders, inventory, financials, and campaigns keeps running without frequent manual re-authorization.
