Microsoft has announced an important Partner Center API change for partners that automate catalog availability, ordering readiness, or pre-sales validation workflows. A new Check Inventory by Resource Type API is now available, and the existing Check Inventory API is scheduled to retire on September 25, 2026.

For partners, the practical message is straightforward: if your integration currently calls /v1/extensions/product/checkinventory, you should plan and complete a migration to /v1/extensions/product/checkinventorybyresourcetype well before the retirement date. The response contract is intended to remain familiar, but the request model changes because Microsoft now requires inventory checks to be filtered by resource type.

What changed

The current Check Inventory API has historically been used to determine whether a catalog item is available, commonly as part of a quote, checkout, provisioning, or eligibility process. Microsoft is now introducing a more specific endpoint: Check Inventory by Resource Type.

The new endpoint adds a required resourceType parameter. Instead of asking for inventory availability only at a broad catalog or market level, partners now indicate the type of Azure resource being checked, such as virtual machines, SQL databases, or Cosmos DB resources.

The new endpoint is:

/v1/extensions/product/checkinventorybyresourcetype

The retiring endpoint is:

/v1/extensions/product/checkinventory

Microsoft’s announced retirement date for the existing endpoint is September 25, 2026. After that date, partners should not expect the old API path to remain available for production workflows.

Why Microsoft is making this change

The key driver is scale and precision. Azure availability is no longer a simple question of whether a product is available in a country or region. Availability can vary based on the underlying resource type, service capacity, configuration, and other service-specific constraints.

For partner systems, that means a broad inventory check may become too coarse. A customer may be eligible to buy one type of resource while another resource type has different availability behavior. By requiring the resource type in the request, Microsoft can return inventory information that is more targeted and better aligned with how Azure services are actually consumed.

This also helps Microsoft manage data growth behind the API. Instead of expanding a general-purpose inventory call indefinitely, the new API narrows the query so that inventory checks can remain performant as service catalogs and availability rules continue to grow.

Default behavior and partner impact

The most important operational impact is that integrations using the existing endpoint need a code change. This is not just a documentation update. Any system that builds Partner Center inventory requests must be reviewed to confirm whether it calls the retiring path.

Common places to check include:

- Custom commerce portals used by CSP customers or sales teams
- Internal quote-to-order platforms
- Automated eligibility checks before checkout
- Provisioning orchestration tools
- Middleware that validates catalog item availability
- Scripts or scheduled jobs that test market availability
- ISV or managed service platforms that call Partner Center APIs on behalf of customers

Because the response contract is not being changed, the downstream impact may be smaller than a full integration redesign. However, request construction and validation logic will need to support the new resourceType requirement. Partners should also confirm how their systems determine the correct resource type for each catalog item.

A good migration plan should not wait until September 2026. Inventory checks often sit in critical transaction paths, and failures may show up as blocked purchases, failed provisioning, or unclear customer-facing errors. The safest approach is to introduce the new endpoint, run it through test scenarios, and then move production traffic with enough time to observe behavior before the old API is retired.

Recommended migration approach

Partners should start with discovery. Search code repositories, API gateways, integration platforms, and configuration files for the old path /v1/extensions/product/checkinventory. In larger environments, it is common for the same API call to exist in more than one service or automation script.

Next, map current inventory-check scenarios to the supported resource types in Microsoft’s new documentation. This is the step that may require the most business logic. If your application presents a general product catalog, it may need a reliable way to associate each inventory request with the correct resource type before calling Partner Center.

After that, update the API client or wrapper used by your integration. If your organization centralizes Partner Center API calls behind a shared internal library, make the change there first and publish a new library version. If multiple teams call Partner Center directly, create a migration checklist so each team handles the endpoint change consistently.

Testing should include positive and negative cases. Confirm that expected items return inventory results when the correct resource type is supplied. Also test what happens when the resource type is missing, invalid, or mismatched. Customer-facing applications should translate any API validation failures into useful messages rather than generic checkout errors.

Finally, monitor production closely after rollout. Track API error rates, latency, and inventory-related order failures. If possible, compare results from the old and new endpoints during a controlled transition period to catch differences before the retirement deadline becomes urgent.

Partner next steps

Partners using Partner Center inventory APIs should take the following actions:

  1. Identify every integration that calls the retiring Check Inventory endpoint.
  2. Review Microsoft’s Check Inventory by Resource Type documentation and supported resource types.
  3. Update request logic to include the required resourceType value.
  4. Validate the new endpoint in test and production-like scenarios.
  5. Move production traffic well before September 25, 2026.
  6. Monitor transaction paths that depend on inventory checks, especially checkout and provisioning workflows.

Bottom line

This is a mandatory API migration for partners using Partner Center inventory checks. The new Check Inventory by Resource Type API is designed to provide more precise and scalable availability checks, but partners must update integrations before the existing endpoint retires on September 25, 2026. Treat this as a planned engineering change now rather than an urgent compatibility issue later.

Microsoft source: Microsoft source