API Reference
The portal you and your users interact with is a React SPA on top of a REST API, and part of that API is supported for your own automation: read the catalog, check the status of a request, see which updates are available, watch a deployment, and approve or reject a request as yourself.
There are two supported ways to call it: as a signed-in person with a delegated token, or unattended from a customer-controlled managed identity, typically an Azure Automation Account. Neither uses a client secret or a certificate. See Authentication.
Not every endpoint supports both, and the MI column below says which do. Approve and reject are people only: a managed identity is not an approver.
The supported API
Section titled “The supported API”This is the whole of it, deliberately. It is small because we would rather publish a handful of endpoints we will keep stable than a long list we might move.
Catalog
Section titled “Catalog”| Method | Path | What it answers | MI |
|---|---|---|---|
GET | /api/apps | The apps this caller can see | Yes |
GET | /api/apps/paginated | The same, a page at a time, for a large catalog | Yes |
GET | /api/apps/{id} | One app’s detail | Yes |
A managed identity is not an administrator, so it sees the visible, supported catalog exactly as an ordinary person does.
Requests and approvals
Section titled “Requests and approvals”| Method | Path | What it answers | MI |
|---|---|---|---|
GET | /api/requests | Your own requests, and their status | No |
GET | /api/requests/{id} | One request’s status | No |
GET | /api/requests/pending | The requests waiting for your decision | No |
POST | /api/requests/{id}/approve | Approve one, as yourself | No |
POST | /api/requests/{id}/reject | Reject one, with a reason | No |
These are all about a person. “Mine” and “waiting for your decision” have no meaning for a workload, and an approval is a named person’s decision that the product will not record unless it can attribute it.
Approve and reject go through exactly the same rules as the portal, because they go through the same code. The person is established from the validated token, a requester cannot decide their own request, the current approval stage must name you or a group you belong to, the decision is claimed under a concurrency check so two approvers acting at once cannot both succeed, a rejection requires a reason, and the audit record names the person who actually acted.
There is no way to approve something through the API that you could not approve in the portal.
Deployment and packaging status
Section titled “Deployment and packaging status”| Method | Path | What it answers | MI |
|---|---|---|---|
GET | /api/admin/update-deployments | Update rollouts and their state | Yes |
GET | /api/admin/update-deployments/{id} | One rollout, including per-ring progress | Yes |
GET | /api/packaging/jobs | Packaging jobs and their state | Yes |
GET | /api/winget/updates/available | Apps with a newer version available upstream | Yes |
For a person these need an administrator. For a workload the AppStore.Automation.Read role permits
these reads only; it confers no other administrative access.
/api/winget/updates/available is the one built for a specific job: a vulnerability-driven workflow
reads it to find out whether an update exists before asking a person to approve deploying it.
Everything else is internal
Section titled “Everything else is internal”The portal calls many more endpoints than these. They are the portal’s own, and they are not a contract: they may change shape, move or disappear in any release, without a deprecation notice.
If you call one, it may work today and stop working after an update. Some of them look inviting, particularly the ones that publish apps or control deployments. They stay internal because publishing a mutation is a promise about its behaviour, and we are not ready to make that promise yet.
If an endpoint you need is missing from the list above, ask. Adding one is easy, and knowing what customers actually automate is how the list should grow.
The OpenAPI spec
Section titled “The OpenAPI spec”Generated from the running API at https://<your-app-store-host>/swagger/v1/swagger.json, with an
interactive Swagger UI at https://<your-app-store-host>/swagger.
Since 1.39.0 both are served only when the API runs in the Development environment or when the
AppSettings__EnableSwagger app setting is true. In a standard deployment they are off. To pull the
spec, set the app setting to true in the App Service configuration, download it, and set it back.
The spec describes every route the API exposes, including the internal ones. Being in the spec does not make an endpoint supported; the list above does.
Where reporting lives
Section titled “Where reporting lives”App Store’s API covers operational integrations: reading the catalog, checking a request, watching a deployment. Anything that is a reporting or data-export workload, such as BI dashboards, data warehouse loads or ad-hoc analytics, lives in BI for Intune rather than here. BI for Intune publishes a Power BI semantic model you can query through the XMLA endpoint, the Power BI REST API, dataflows or direct export. Microsoft already built that API; App Store does not duplicate it.
What’s next
Section titled “What’s next”- Authentication: get a delegated bearer token.
- PowerShell examples: runnable scripts.