selling-partner-api-models: the spec repository behind Amazon Selling Partner API clients

A specification repository, not a package you import

The amzn/selling-partner-api-models repository contains OpenAPI models for developers to use when writing software that calls the Selling Partner APIs. The README puts it plainly: it holds Swagger models, and developers can use swagger codegen to generate client libraries from them.

That distinction sets the whole shape of the project. There is no install step, no runtime dependency to add to a manifest and no function to call. What you get is a description of the request and response shapes of Amazon's seller APIs, and the tooling inputs to turn that description into a client in the language of your choice.

The primary language listed for the repository is Mustache, which is a template language, and that is the tell for what the project actually is. Mustache templates are what swagger-codegen consumes to shape generated code, so a repository whose dominant file type is Mustache is a code generation resource rather than an application.

For an engineer, the practical question is not whether to use this repository, but when to regenerate. The models are described as the currently available set, so they move as Amazon's APIs move, and a client generated months ago is a client generated from an older truth.

Three directories with three different jobs

The repository has a small top level and a clear division inside it. Alongside the usual .github directory, the contribution files and the licence files, there are three content directories.

The models directory contains all of the currently available Selling Partner API models. The schemas directory contains all of the currently available Selling Partner API schemas. The clients directory contains the two published client libraries and the templates used to generate them.

The split between models and schemas is the part that trips people up when they first open the repository. A model and a schema are not the same artifact in the OpenAPI world, and this project keeps both sets side by side rather than collapsing them into one. If your generator expects one and not the other, the repository gives you both and leaves the mapping to you.

Everything sits on the main branch, with no separate release branches visible in the top level. That is consistent with how the project is consumed: you take the current content, not a versioned package, and the clients directory is regenerated from it.

The clients directory holds Java, C# and the Mustache templates

The clients directory is the part that produces something you can commit to your own repository. It contains a Java library named sellingpartner-api-aa-java and a C# library named sellingpartner-api-aa-csharp, and alongside them the Mustache templates used with swagger-codegen. The templates are located in resources/swagger-codegen.

Those two directory names are the ones to look for when you are cloning.

sellingpartner-api-aa-java
sellingpartner-api-aa-csharp
resources/swagger-codegen

The templates matter because they are where the authentication and authorization functionality comes from. The README states that the templates exist for use with swagger-codegen to generate client libraries with authentication and authorization functionality included, which is the hard part of talking to the Selling Partner APIs and the part most teams would otherwise have to write themselves.

So the repository gives you three starting points rather than one. You can take the Java or the C# library as it stands, or you can take the Mustache templates and run them through swagger-codegen yourself against the models, which is the route that lets you control the generator options and the shape of the output. The generator itself is not part of this repository, it is the separate swagger-codegen project, and the README points at both the codegen repository and its own tool page.

The documentation and the support path live somewhere else

The README is explicit that this repository is not where the documentation is. It refers developers to the selling-partner-api-docs repository for additional documentation, and specifically to the Selling Partner API Developer Guide for instructions on how to get started. The models here are the machine readable half of the story; the guide is where the process of obtaining credentials, registering an application and handling the request signing lives.

The same split applies to problems. The README carries a note directing any issue related to the Selling Partner API itself, whether a bug or a troubleshooting question, to Developer Support, with the stated reason being that the right team can then handle the input and channel it to the development team. The reasoning is about routing rather than suppression: API behaviour questions belong to the team that owns the API, and this repository owns the description of it.

Two smaller conventions point the same way. Security issues are handled through the contributing guide, which the README links under a security section, and the repository carries a code of conduct. For a project maintained under a corporate umbrella, that is the expected shape: the artefacts are open, and the conversation about them is routed through named channels.

Apache-2.0 with a NOTICE file that travels with the models

The licence section states that the project is licensed under the Apache 2.0 License, and the repository root carries both a LICENSE file and a NOTICE file. The presence of NOTICE next to LICENSE is the detail that matters when you redistribute.

Apache 2.0 asks that the licence text and the notice travel with copies of the work, and the NOTICE file is where attribution details live when a project has them. If you copy models, schemas or generated clients into a product or an internal library, the safe path is to keep both files, and if your generated clients carry the attribution headers that the templates put there, do not strip them.

This is a description of what the licence asks and not advice about your obligations. Teams with a compliance function should read the LICENSE file themselves and ask that function, because the same rules apply to any vendored Apache licensed artefact and most organisations already have a position on them.

The code of conduct and the contribution guide sit alongside the licence files, and a NOTICE file at the root of a schema repository is a reminder that these models carry provenance from upstream systems rather than being authored from nothing.

No releases, so a pinned commit is the only stable reference

The maintenance picture is defined by two facts and one absence. The repository is not archived, and the last push was on 2026-10-17, so the models are being kept current. The default branch is main. And there are no GitHub releases.

That absence has a practical consequence. For a package registry you would pin a version, and for a release tarball you would pin a tag. Here there is neither, so the only reproducible reference is a commit hash, and a team that wants a stable build has to record that hash in its own repository, because upstream will keep moving main as the APIs change.

The rate of change is set by Amazon rather than by the maintainers, and the README describes the models as the currently available set, which means a generator run today and a generator run next quarter may produce different method names and different payload fields.

The practical habit that follows is simple: regenerate on a schedule, diff the output, and treat a change in the generated client as a change in your system rather than as a routine dependency bump. For a seller-facing integration, that is the difference between catching a renamed field in a pull request and discovering it in production.

Editorial conclusion

Adopt this repository when you maintain software that calls the Selling Partner APIs and want the request and response shapes to match what Amazon currently publishes, rather than the shapes you typed out last year. Do not adopt it as a runtime dependency, since it contains models, schemas and templates rather than an installed client, and expect to regenerate your client whenever the models change. Before wiring anything up, read the Selling Partner API Developer Guide in the selling-partner-api-docs repository for the getting started steps, decide whether the Java or the C# client in the clients directory matches your stack, and keep the Apache-2.0 NOTICE file from the repository root with any redistribution you make.

Frequently asked questions

Official sources

1. amzn/selling-partner-api-models on GitHub
2. Issues
3. License: Apache-2.0
4. README