eBay’s 2026 Modern APIs Migration (Trading XML to GraphQL & REST): What Changes for Developers and Resellers

I wanted to start a dedicated thread here in Marketplaces for everyone building tools, scripts, or managing high-volume multi-channel catalogs on eBay.

eBay has published its official Modern APIs Migration Guide, laying out the roadmap that replaces three foundations of legacy eBay software:
1. Traditional SOA/XML APIs (most notably the 20-year-old Trading API: AddItem, ReviseItem, RelistItem, EndItem, GetItem, GetOrders, GetSellerList, GetCategories, GetCategoryFeatures)
2. Post-Order API v2 (cancellations, returns, inquiries, and cases)
3. Platform Notification XML Events (ItemSold, FixedPriceTransaction, ItemListed, BestOffer, AskSellerQuestion)

I just published a full technical breakdown on our blog—eBay Modern APIs Migration Guide (2026): Moving from Trading XML & Post-Order APIs to GraphQL and REST—and wanted to highlight the biggest architectural changes that affect both developers and everyday resellers.

---

1. The GraphQL Listing API Replaces AddItem, ReviseItem, EndItem & GetItem

Instead of sending giant operation-specific XML envelopes (AddFixedPriceItem, ReviseInventoryStatus, GetItem), listing management is moving to the GraphQL Listing API:

• Create: createListing (replaces AddItem, AddFixedPriceItem, AddItems, and RelistItem)


• Update: updateListing and bulkUpdateInventory (replaces ReviseItem, ReviseFixedPriceItem, and ReviseInventoryStatus)


• End: endListing (replaces EndItem, EndFixedPriceItem, EndItems)


• Read / Search: sellerListings and sellerListingSearch (replaces seller-owned GetItem, GetSellerList, GetMyeBaySelling)

Four Breaking Rules Developers Need to Watch Out For:

1. Global Seller-Wide SKU Uniqueness (inventoryTrackingBySku = true): In the old XML Trading API, listing-level SKU was loosely enforced unless you set InventoryTrackingMethod = SKU. In the GraphQL Listing API, whenever you supply a listing-level SKU, inventoryTrackingBySku defaults to true and enforces uniqueness across all eBay marketplaces for that seller. Even listing on eBay US (EBAY_US) and eBay UK (EBAY_GB) shares the same uniqueness scope! If you reuse one internal SKU across multiple eBay listings, you must mint distinct eBay SKUs (e.g., SKU-US-001, SKU-UK-001) and map them locally. 2. Mandatory Variation-Child SKUs: Every variation inside a multi-variation listing must have a unique SKU. 3. Explicit Quantities & Required Idempotency Keys: createListing no longer defaults quantity to 1—you must explicitly pass quantity for every single-item or variation listing, and every createListing mutation requires an idempotency key so network retries never create duplicate live listings. 4. No VerifyAddItem Sandbox Flag: VerifyAddItem is retired without a 1:1 replacement. Schema validation and sandbox testing replace dry-run XML calls.

---

2. Paid Orders vs. Unpaid Item Commitments & Purchase Quotes

One of the smartest (and most disruptive) changes in the migration guide is how eBay separates paid orders from unpaid commitments:

• In the legacy XML GetOrders call, unpaid auction wins and unpaid Best Offers showed up mixed into your order feed alongside paid transactions.


• In the modern REST architecture:

- Order API v1 (getOrders, getOrder) only returns paid orders.
- Item Commitment API v1 (getItemCommitments, getItemCommitment) tracks unpaid line items where a buyer won an auction or committed to buy but hasn't completed checkout yet.
- Purchase Quote API v1 (initiatePurchaseQuote, getPurchaseQuote) replaces the old SendInvoice XML call when a buyer requests a combined shipping total (BUYER_REQUESTED_PURCHASE_QUOTE).

For cross-listing and auto-delisting tools like Pivotal Reseller, this distinction is huge: you want to know the second an Item Commitment happens so you can hold inventory, and the exact second ORDER_CONFIRMATION fires so your accounting ledger records landed profit and shipping label liabilities.

---

3. Hard 2026 Decommissioning Deadlines Already on the Calendar

While the GraphQL Listing API, Order API, and Communication APIs are currently in Limited Release, several metadata and catalog calls have hard 2026 shutoff dates:

---

4. Post-Order API & Platform Notifications Consolidation

• Post-Order Cancellations, Inquiries & Returns move out of the legacy /post-order/v2/* silo directly into the REST Order API v1 (/sell/order/v1/order_cancellation, /sell/order/v1/order_inquiry, /sell/order/v1/order_return) and Item Commitment API v1.
• Platform Notifications consolidate dozens of chatty XML webhooks (ItemListed, ItemRevised, ItemClosed) into unified Notification API Topics like LISTING (with reason: CREATED | UPDATED | ENDED), ORDER_CONFIRMATION, OFFER_ACTIVITY, and NEW_MESSAGE.

---

How We’re Handling This in Pivotal Reseller

Because Pivotal Reseller stores your entire inventory ledger in a local SQLite database on your PC (data/pivotal.db architecture), we already maintain a clean separation between your internal master SKU and per-marketplace listing identifiers, plus deterministic 4-tier shipping policy mapping (Flat Rate 1–4 in v0.1.9).

Questions for the community:
1. For those of you running multi-marketplace stores or custom eBay integrations, do you currently reuse listing-level SKUs across multiple eBay listings or international eBay sites?
2. How do you prefer auto-delist to behave when an eBay buyer triggers an unpaid Item Commitment (accepted offer / auction win) vs. a paid Order—delist immediately on commitment, or pause until payment clears?

Read the full breakdown here: eBay Modern APIs Migration Guide (2026) on the Pivotal Reseller Blog and share your thoughts below!

— Dan