Microsoft has issued a final reminder that the legacy Partner Center Check Inventory API will retire on September 25, 2026. Partners that still use this endpoint for availability checks should treat this as an immediate migration item, not a future cleanup task. The replacement, Check Inventory by Resource Type, is already available and is intended to handle inventory checks in a more specific and scalable way by requiring partners to identify the resource type they want to validate.

For Cloud Solution Provider (CSP) partners, distributors, marketplaces, and software teams that automate catalog or Azure availability checks through Partner Center APIs, the practical message is straightforward: if your integration still calls the older Check Inventory API, it needs to be updated before the retirement date. After that date, requests to the legacy API should be expected to fail or become unsupported, which can affect ordering workflows, validation logic, customer portals, and internal provisioning tools.

What is changing

Microsoft is replacing the previous Check Inventory API with the newer Check Inventory by Resource Type API. The key functional change is the addition of a resourceType parameter. Instead of asking Partner Center to check inventory in a broad way for a catalog item, integrations now need to specify the kind of resource being checked.

This change does not appear to be about changing the response contract for partners. Microsoft describes the new API as a way to support the increasing complexity of Azure services while keeping the response model stable. In other words, the input becomes more precise, while the consuming systems should be able to keep broadly similar handling once the integration is updated.

The retirement date for the older API is September 25, 2026. The reminder was published on September 18, 2026, giving partners a short final window to confirm whether they are still using the old endpoint and to complete migration work.

Why Microsoft is making this change

Inventory availability has become more complicated as Azure services have expanded. Availability can depend not only on a product or catalog item, but also on the specific resource type involved. A generic inventory check is less suitable when the same broad catalog context can contain multiple resource types with different availability constraints.

By requiring a resource type in the request, Microsoft can route and process inventory checks with more context. That should help Partner Center scale better as the number and complexity of services grows. It also reduces ambiguity for partners because an inventory check becomes tied to the exact resource category being evaluated.

For partners, this is a familiar pattern in cloud platform APIs: broad operations are gradually replaced with more explicit calls that provide better filtering, better performance, and fewer assumptions. The extra parameter may seem small, but it can require meaningful review if the older API is used in multiple internal services or customer-facing systems.

Who is impacted

The impacted audience is any partner using Partner Center APIs for inventory checks. This may include direct CSPs, indirect providers, indirect resellers with custom tooling, marketplace operators, managed service providers, and independent software vendors that built automation around Partner Center catalog and ordering workflows.

The most obvious risk is in systems that perform inventory validation before presenting offers, accepting customer orders, or triggering provisioning. If those systems depend on the retiring endpoint, the user experience can break even if the rest of the ordering process is technically unchanged.

Partners should also check less visible integrations. Inventory checks are often embedded in scheduled jobs, quoting tools, back-office order validation, pre-provisioning checks, and exception-handling workflows. A partner may have migrated its main commerce application but still have older scripts or middleware using the legacy API.

Expected impact if no action is taken

If no changes are made before retirement, integrations that call the old Check Inventory API may stop working after September 25, 2026. Depending on how error handling is implemented, this could show up as failed inventory validation, blocked orders, incorrect availability messages, or generic API errors in logs.

The business impact depends on where the API call sits in the partner workflow. If the check is advisory, staff may be able to work around failures manually. If it is mandatory before checkout or provisioning, the retirement can interrupt sales or delay customer delivery. If the failure is hidden inside an asynchronous job, teams may not notice until downstream orders or provisioning attempts begin to fail.

This is also a supportability issue. Once the API is retired, troubleshooting should focus on migration rather than trying to keep the old integration alive. Partners should avoid spending time building retries or exception logic around an endpoint that Microsoft has already scheduled for removal.

Partner action plan

First, inventory your code and configuration for Partner Center inventory calls. Search for the legacy Check Inventory API endpoint in application code, integration platforms, API gateways, serverless functions, scripts, and documentation. Include both production and non-production environments, because test systems often contain older integration paths that later get copied forward.

Second, map each legacy call to the new Check Inventory by Resource Type API. For every inventory check, identify the correct resourceType value required by Microsoft documentation. This is the main design step: the new API is not just a drop-in URL change if your current code does not already track resource type at the point where the check is made.

Third, update request-building logic. Make sure the integration passes the resource type explicitly and validates it before making the API call. If the resource type is derived from product metadata, catalog data, or internal offer configuration, confirm that the source is reliable and kept current.

Fourth, test the full workflow, not only the API call. A successful HTTP response is not enough. Partners should verify that quoting, checkout, provisioning, logging, monitoring, and exception handling still behave correctly. Pay particular attention to customer-facing messages and internal support dashboards, because these are the places where unclear inventory failures can create operational noise.

Fifth, monitor after deployment. Once migrated, track error rates, response times, and any unexpected inventory mismatch reports from sales or support teams. Since Microsoft introduced the new approach to address scale and complexity, partners should also review whether any old assumptions about broad availability still exist in their own business logic.

Practical implementation considerations

Development teams should treat this as a small but time-sensitive API migration. The response contract may remain similar, but adding resourceType can affect data models, request validation, and test fixtures. If your integration layer has shared Partner Center API clients, update the shared client first and then migrate consuming services in a controlled way.

For organizations with multiple teams, assign ownership quickly. Partner Center API dependencies often sit between commerce, operations, and platform engineering teams. A short retirement window can create confusion if nobody owns the legacy inventory check. The safest approach is to identify all callers, create a migration checklist, and confirm production deployment before the deadline.

Partners should also update internal runbooks. If support or operations teams see inventory check failures after September 25, they should know that the legacy API retirement is a likely cause. Clear runbook notes can prevent unnecessary escalation and reduce time spent diagnosing a known migration issue.

Bottom line

The legacy Partner Center Check Inventory API is being retired on September 25, 2026, and Microsoft is directing partners to use the Check Inventory by Resource Type API instead. The required change is conceptually simple: include resource type in the inventory check. The operational risk is that older integrations may be hidden in ordering, validation, or provisioning workflows.

Partners should confirm immediately whether they still use the retiring API, update integrations to the new resource-type-based endpoint, test end-to-end workflows, and monitor production behavior after deployment. With the deadline imminent, this should be handled as an active service-readiness item rather than a routine backlog task.

Microsoft source: Reminder: Check Inventory API retiring September 25, 2026