eBay’s legacy Product API is scheduled to be decommissioned on August 15, 2026. That deadline matters most to sellers, agencies and software teams that still use the old product-detail, product-search or compatibility calls in listing tools, catalog workflows or internal reporting. eBay’s developer documentation identifies the affected Product API calls and points developers toward the newer Catalog and Metadata APIs.
This is not a cosmetic documentation change. A deprecated API can remain in a working integration for months, which is exactly why a shutdown date is risky: the operational failure may first show up in a bulk listing run, a replenishment task or a catalog-enrichment job rather than in a planned engineering test. The sensible response is to locate every dependency, decide which supported service replaces it and prove the replacement with real listing scenarios before the cutoff.
eBay’s API deprecation status page lists findProducts, getProductDetails and getProductCompatibilities among Product API calls slated for decommissioning on August 15. eBay’s individual reference pages direct users of the old product-detail calls to the Catalog API, while compatibility guidance points to the Metadata API.
What is changing
eBay’s Product API was built around legacy catalog lookups. Depending on the call, an integration could search catalog products, retrieve product details by eBay product identifier or external identifier, or retrieve compatibility information. The developer portal now labels those calls as deprecated and gives August 15, 2026 as their decommissioning date. A system that invokes one of those methods after the service is retired should not be assumed to receive a usable response.
The replacement is not necessarily a one-for-one code rename. eBay’s current API portfolio separates jobs more clearly. The Catalog API is the place to evaluate for current catalog-item lookup needs, while the Metadata API is relevant where a workflow relies on category rules or product-compatibility metadata. That distinction is important for sellers because a bulk tool may combine several old calls behind one “find item details” button.
For operations teams, the practical question is not whether someone remembers building against Product API. It is whether any live service still calls it: a listing app, spreadsheet connector, feed processor, repricing helper, warehouse workflow, middleware account or an agency-managed integration. The owner may be a vendor rather than the seller, so the audit needs both technical and commercial follow-through.
Who should treat this as urgent
The highest-risk group is a seller or technology partner that uses eBay catalog data to create or revise listings. A workflow may pull an ePID or UPC, populate product details, check parts fitment or suggest an item before sending an offer live. If the legacy call disappears, the user could face failed automation, incomplete data or manual work at the moment inventory needs to be updated.
Parts and accessories sellers deserve special attention. eBay’s current developer guidance distinguishes product catalog functions from compatibility and policy requirements. Its Parts and Accessories easy-returns documentation also directs developers to supported account-policy and listing flows when a listing must meet marketplace rules. Do not assume one legacy catalog call covered every aspect of a vehicle-parts workflow.
Sellers who only create listings by hand in Seller Hub may have little or no direct migration work. Even then, they should ask any connected software provider a pointed question: “Do you make Product API calls, and what has changed before August 15?” A written answer is more useful than a general assurance that a tool is “eBay compatible.”
Build a dependency map before changing code
Start with an inventory of every eBay-connected workflow. Include apps installed through the eBay ecosystem, custom integrations, APIs called from a data warehouse, scheduled jobs, browser extensions and outside agencies. Record the workflow owner, the business action it supports, its API credentials, its last successful run and the consequence if it fails.
Next, inspect logs, source code and vendor documentation for the affected method names: findProducts, getProductDetails and getProductCompatibilities. Search for endpoint paths too, because older libraries may hide the public method names. A quiet integration is not automatically safe; it may simply run only when a new item, a seasonal shipment or a specific category is processed.
Then classify each dependency. Some systems may only display optional enrichment, where a temporary manual lookup is manageable. Others may create, update or validate thousands of listings and need a tested replacement before the next scheduled cycle. That classification should guide the order of work and the rollout plan.
Test the replacement around seller outcomes
Migration should be tested from the seller’s result backward, not only from a successful HTTP response. Select representative products: a common catalog item, a product with variations, an item using a UPC, a parts-and-accessories listing if applicable and a case that previously returned no match. Compare what the old workflow produced with what the supported APIs and current listing flow produce now.
Check the fields that matter to customers and operations: the correct product match, brand and attributes where applicable, category choices, compatibility information, images, price, quantity, shipping settings and any policy validations. A replacement can technically succeed while still returning a different data shape that breaks a downstream import or makes an operator choose the wrong item.
Run the test in a limited environment or on a controlled set of draft listings where possible. Preserve a record of inputs, outputs, timestamps and errors. If a vendor owns the integration, ask for the same evidence: which deprecated calls were removed, which supported eBay API is now used and what seller-facing workflows were tested.
Seller action list for the next 24 hours
- Name an owner. Assign one person to coordinate the Product API audit and collect vendor confirmations.
- Find the calls. Search code, logs and integration settings for eBay Product API usage and the three affected calls.
- Contact vendors. Ask listing, catalog, fitment and middleware providers for their migration status and any action required in your account.
- Map each workflow to a supported path. Use eBay’s current Catalog API and Metadata API documentation to determine the appropriate replacement; do not guess from a method name.
- Test real cases. Validate representative catalog lookup and listing workflows before the decommissioning date.
- Protect the fallback. Keep a manual process for critical listing revisions until the migrated workflow has completed successfully in production.
Why this matters beyond one API
Marketplace integrations are part of a seller’s operating infrastructure. They shape whether catalog facts are correct, whether inventory can be listed on time and whether staff can respond when a product needs a revision. The closer a platform deadline is, the less useful a broad “we will handle it” promise becomes. Sellers need a confirmed owner, an explicit replacement path and a small set of passed production checks.
The August 15 deadline is an opportunity to remove uncertainty rather than a reason to rush untested code. Use eBay’s primary documentation as the source of truth, make the migration decision at the workflow level and verify the actual merchant outcome. That is how a catalog API retirement stays a contained technical change instead of becoming an avoidable listing outage.
