How should sellers control an Amazon Merchant Token?
Maintain a controlled mapping between the token, seller account, legal business, integration, environment, owner, and authorization record. Validate that mapping in Seller Central before onboarding, migration, incident recovery, or any production change, and reject a connector setup that cannot prove which account it will act on.
Amazon describes the Merchant Token as a unique seller identifier used with third-party software and says it cannot be shared with other sellers or used for different seller accounts. An identifier is not a substitute for authorization: current SP-API integrations use Amazon’s approved authorization workflow and scoped roles.
Build a Merchant Token register
- Record the exact seller account, business owner, store scope, token value location, approved integration, and internal system owner.
- Classify the token as an account identifier and store authentication credentials or refresh tokens in a separate approved secret system.
- Document whether the integration is public or private, its authorization owner, roles, data scope, production status, and renewal requirements.
- Separate sandbox, test, and production configurations so copied settings cannot route test jobs into a live account.
- Restrict who may view, enter, export, or change identifiers and who may authorize the corresponding application.
- Log every onboarding, migration, account change, provider change, failed validation, and decommissioning decision.
Validate before enabling production
Have one person read the current token and account context from Seller Central and a second person compare it with the integration record. Run a non-destructive identity or read-only validation where the approved application supports it, then confirm that returned marketplaces, seller context, and expected records match the change ticket.
If the connector reports an invalid seller identifier, wrong account, or authorization error, stop the job. Recheck the seller account, environment, application authorization, roles, and configuration source. Do not solve the error by borrowing another seller’s token, reusing a production token in test, or sharing primary sign-in credentials.
Use a Merchant Token control checklist
- Each token maps to one verified seller-account record and an accountable business owner.
- The token is not treated as a password, OAuth grant, refresh token, or user credential.
- Application authorization, roles, data scope, and environment are documented separately.
- A two-person account-context check is completed before production enablement or migration.
- Wrong-account, invalid-identifier, and authorization failures stop writes until resolved.
- Decommissioning removes integration access and configuration references without deleting audit evidence.
Scope and exceptions
Merchant Token labels, visibility, plan eligibility, account structure, and integration requirements can vary. Marketplace identifiers, seller IDs, application IDs, authorization tokens, user permissions, and service-provider access are different objects; do not assume one identifier grants or revokes another type of access.
Review Amazon’s current [Merchant Token guidance](https://sellercentral.amazon.com/seller-forums/discussions/t/eb2bfdb3-c26c-424f-b32b-0cca441fb507) and [SP-API onboarding and authorization guidance](https://developer-docs.amazon.com/sp-api/docs/onboarding-overview). Use the live Account Info and application authorization pages for the applicable account.
Related Amazon seller guides
- [Pilot an SP-API integration without losing data control](https://amazonmargincalculator.cloud/blog/amazon-sp-api-integration-control-pilot)
- [Offboard service providers without breaking operations](https://amazonmargincalculator.cloud/blog/amazon-service-provider-access-offboarding)
- [Evaluate Selling Partner Appstore apps before connecting them](https://amazonmargincalculator.cloud/blog/amazon-selling-partner-appstore-evaluation)