Microsoft has issued a final reminder for partners who still use the older Partner Center Check Inventory API: the endpoint is scheduled to retire on September 25, 2026. A replacement, Check Inventory by Resource Type, is already available and should be adopted before the retirement date.
For partners with automation around Azure catalog availability, provisioning workflows, marketplace ordering, or internal sales tools, this is a small-looking API change that can have an outsized operational impact. If an integration still calls the retiring endpoint after the deadline, inventory checks may fail, and downstream systems that depend on those checks may no longer be able to confirm availability before presenting or placing offers.
What is changing
Microsoft is replacing the previous Check Inventory API with a newer version that requires inventory checks to be scoped by resource type. The new Check Inventory by Resource Type API keeps the overall purpose familiar: partners can still check whether catalog items are available before moving further into a transaction or provisioning flow.
The important change is the additional resource-type context. Instead of asking for inventory availability in a broad way, integrations must now include the relevant resourceType parameter. Microsoft says the response contract remains unchanged, which should reduce the amount of downstream refactoring required. However, the request-building logic needs attention because calls must now provide the right resource type for the catalog item being checked.
The retiring API is scheduled to stop being supported on September 25, 2026. Any partner system still using the old endpoint should be considered at risk.
Why Microsoft is making the change
Azure services have grown more complex, and availability is no longer always a simple catalog-level question. Availability can depend on the specific type of resource being requested, not only the broader offer or catalog item. A generic inventory check can therefore be too coarse for modern Azure inventory scenarios.
The replacement API is designed to handle this additional complexity more directly. By requiring resourceType, Microsoft can evaluate availability in a way that better matches how Azure capacity and service availability are represented internally. The change is also intended to improve scalability and performance as catalog and inventory data continue to grow.
For partners, the key point is that this is not just a cosmetic endpoint rename. The new request model asks integrations to be more explicit about what kind of resource availability they are checking.
Who is impacted
This announcement affects all partners using Partner Center APIs for inventory checks. That may include direct API consumers as well as partners who rely on custom tools, middleware, ERP integrations, quote-to-order systems, procurement portals, or automated provisioning workflows.
The highest-risk environments are those where inventory checks happen in the background and are not visible to end users. For example, a sales portal may quietly call Partner Center before showing an item as orderable, or a provisioning workflow may validate inventory before creating an order. If those calls fail after retirement, the symptom may appear somewhere else: unavailable products, blocked order flows, failed validation, or confusing error messages in internal tools.
Partners should also check older code paths. Inventory checks are often implemented once and then left untouched for years. Even if the main platform has been updated, legacy scripts, regional tooling, test environments, or partner-developed connectors may still call the retiring API.
Expected impact if no action is taken
After September 25, 2026, integrations that still depend on the older Check Inventory API may no longer receive valid inventory responses. The exact user-facing impact will depend on how each partner has built error handling.
In some systems, failed checks may prevent users from continuing with a purchase or provisioning request. In others, failures may be logged but not clearly surfaced, creating a risk that teams continue working with stale assumptions about availability. Poorly handled failures could also cause retry storms, unnecessary support tickets, or manual workarounds during quoting and order processing.
Because Microsoft says the new API does not change the response contract, partners may be able to contain the work to the request layer and related mapping logic. Still, the migration should be tested end to end. A successful API call is not the same as a working business process.
Partner action checklist
Partners should treat this as an urgent migration item if they have not already completed the change.
- Inventory your integrations. Search codebases, automation jobs, API gateways, and connector configurations for calls to the older Check Inventory API. Include non-production environments and one-off scripts.
- Map catalog items to resource types. The new API requires a
resourceTypevalue. Review Microsoft’s documentation for supported resource types and confirm how each product or scenario in your systems should be mapped.
- Update request construction. Modify API clients so inventory checks use the new Check Inventory by Resource Type endpoint and include the correct resource type parameter.
- Validate response handling. Microsoft indicates that the response contract is unchanged, but partners should still confirm that parsing, logging, retry behavior, and business-rule logic continue to work as expected.
- Run end-to-end tests. Test the full flow: product selection, inventory check, quote or order creation, provisioning handoff, and error messaging. Include both available and unavailable scenarios where possible.
- Monitor after deployment. Add temporary monitoring around inventory-check failures, latency, and unexpected response patterns. Keep this monitoring in place through and after the retirement date.
- Communicate internally. Make sure support, sales operations, and engineering teams know about the deadline. If customers or internal users report ordering issues around the retirement date, teams should know to check inventory API migration status early in the troubleshooting process.
Practical migration guidance
A good migration approach is to isolate the Partner Center inventory check behind a small internal service or library if that is not already the case. That makes the required resourceType handling easier to standardize and reduces the risk of multiple teams implementing inconsistent mappings.
Partners should also avoid hard-coding assumptions without reviewing Microsoft’s supported resource-type documentation. If the mapping is wrong, the API may technically work while still checking the wrong availability context. That can create a more subtle problem than an outright failure.
Where possible, deploy the updated integration before the deadline and compare production behavior against historical metrics. Look for changes in failure rates, latency, and the distribution of availability results. Any unexpected deviation should be investigated before the retiring endpoint is no longer available as a fallback.
Bottom line
The Check Inventory API retirement is imminent. Partners that use Partner Center APIs for inventory validation should move to Check Inventory by Resource Type before September 25, 2026, confirm their resourceType mappings, and test the full business process rather than only the API call.
The change is intended to support more accurate and scalable inventory checks for modern Azure services, but it requires partner action. If your systems still depend on the older endpoint, this should be handled as a time-sensitive production-readiness task.