Problem

The Admin Center endpoint GET …/environments/{environment}/apps returns only a snapshot of installed apps.

It does not expose the lifecycle of a PTE on an environment:

previous versions still present on the service
published but not installed packages
uninstall / unpublish history
enough identity to know that the same App ID + version has already been uploaded (possibly with a different .app file)

Today, reconstructing that view requires combining:

This is a fragile workaround, and it goes against Microsoft’s direction to manage PTEs through the Admin Center API.

Concrete failure

After an uninstall or version upgrade, an older package can remain on the service while GET …/apps no longer shows it.

A later upload / pteInstall of the same App ID + version then fails with:

"A different .app file with the same App ID (…) and version (…) has already been uploaded to our service"

Pipelines cannot reliably detect this through Admin alone.

Add an Admin Center API, for example:GET …/environments/{environment}/apps/{appId}/history

Each entry should allow CI/CD to answer:

which versions / packages exist or have existed for this app on this environment
in which lifecycle state

Suggested fields (illustrative):

version
packageId (or equivalent content identity — critical for same-version / different-package collisions)
state — e.g. installed, publishedNotInstalled, scheduled, unpublished
operationType — e.g. install, uninstall, unpublish, update
operationId, attemptResult, occurredAt

For full lifecycle coverage, add an Admin action to unpublish a non-installed package, equivalent to Microsoft.NAV.unpublish.

Desired targeting: packageId (ideally also appId + version).

Why it matters

Align Admin with the real lifecycle (upload ≠ install ≠ unpublish) and let pipelines detect then clean up cleanly in one place.

STATUS DETAILS

New