eBay Integration – Feature & Process Guide

Pentagon Connect (Hemi) has sold on eBay for years through eBay's legacy Trading API, a long-standing XML-based integration. eBay itself is now retiring that surface piece by piece — category lookups are already gone, order-management fields disappeared in January 2024, and the image-upload call the legacy integration depends on shuts down on 30 September 2026 — so continuing to run purely on the legacy integration carries real, growing risk of things simply stopping working.

"eBay Rework" is Pentagon Connect's in-flight replatform onto eBay's current Sell API family, connected behind a single modern sign-in. It is currently in the sandbox-build/pilot phase — the target architecture, not yet the only thing running in production. Order retrieval is the first flow live on the new integration, and it works independently of whether a merchant's listings have migrated; listing management and the full set of order actions (cancellations, refunds) are following. Until a merchant is fully cut over, their orders and listings continue running on the legacy integration in parallel. Where this guide says "legacy" or "Trading", that's the older integration still serving merchants who haven't cut over; where it says "Rework" or "modern", that's the new one.

Quick Reference

Product Management

Pricing & Stock

Orders & Fulfilment

Refunds, Returns, Cancellations & Claims

Product Management

Creating products

• Today, listings are created and revised through the legacy integration.
• The modern (Rework) model splits a listing into two linked pieces: a product record (keyed by SKU) carrying the content — title, description, category attributes, images, identifiers, condition, weight, quantity — and a separate offer carrying the commercial side — price, category, listing status, VAT rate — plus the live eBay listing ID that orders arrive tagged with.
• Only listings created directly in the modern model, or explicitly migrated across, are visible to it. A listing still on the legacy integration is invisible to the modern product tools, which is why the legacy creation and update path stays running in parallel for any merchant not yet migrated.
• Category-specific requirements are downloaded per eBay marketplace from eBay's own category data and checked locally before a listing is submitted, so a listing missing a required attribute for its category is caught before eBay ever sees it.
• Variants (e.g. by size or colour) are each created as their own linked product record, grouped by a shared variation key — siblings don't need to be submitted together.
• Motors fitment / parts compatibility data carries over unchanged from Pentagon Connect's existing fitment database.
• EU/UK product safety data (GPSR): safety documents (certificates of conformity/analysis, declarations of conformity, instructions for use, safety data sheets, troubleshooting guides, user guides, installation instructions), energy-efficiency label information and image, a product-sheet image, and hazmat data (component, pictogram, signal word, and a conditional hazmat statement) can all be set at product level or account level, with the account-level value acting as a fallback for products with nothing set.
• Auction-style listings are not supported going forward and won't be carried into the modern model in any form.

Updating products

• Price and stock update together in a single combined action — eBay applies both at once, the same way the legacy integration always has.
• Full content updates (title, description, images, attributes) run as a separate action from the price/stock update.
• Protect flags: a product's price can be locked from being overwritten, its stock can be locked, or the product can be excluded entirely from a given update run.
• The modern update path only reaches listings that have been created or migrated into the modern model; a listing not yet migrated is skipped by it and continues to update through the legacy path instead — this is the intended parallel-run behaviour, not a gap.

Deactivating / removing products

• Ending a listing takes it down; a listing can also simply be excluded from further updates via the protect-the-whole-item flag without formally ending it.
• Migrating a listing from the legacy model into the modern model is one-way. Once migrated, that listing can never again be revised through the legacy integration by anyone — including any legacy-based tool the merchant runs themselves. There is no per-listing rollback.
• A handful of older listing features freeze permanently at the point of migration and can never be edited again by anyone, though they remain visible on the listing: buyer requirements, charity donation, listing-designer templates, and enhancements like bold title or gallery-style upgrades.
• Because migration can't be undone, it is always sequenced as the last step for a merchant, only after order and listing flows have been proven out running in parallel.

Pricing & Stock Sync

• Price and stock always update together in one action, never sent to eBay as two separate updates.
• Protect flags are honoured: price-only, stock-only, or the whole product can be excluded from an update run.
• eBay's own bounds on quantity and price are checked locally before sending, so an out-of-range value is caught early rather than bouncing back as a rejected update.
• eBay reports success or failure per product inside a single batch response — a batch as a whole can come back as accepted even though individual products within it failed. A failed product is automatically retried on the next run.
• Very high-volume accounts are routed through a separate bulk file path automatically at large volumes; this is a performance detail invisible to how the feature is used day to day.
• Business policies (fulfilment, payment and return) are read from eBay and kept in sync, but they're configured by the seller in eBay's own Seller Hub — Pentagon Connect reflects and reuses what's there rather than creating or deleting policies. Requires the seller to be opted into eBay's Business Policies programme; accounts that aren't opted in are skipped for policy sync entirely.
• Shipping rate tables (the cost tables a fulfilment policy's shipping cost can reference) are supported on 8 marketplaces only — US, CA, GB, DE, AU, FR, IT and ES. Only the costs inside an existing table can be updated via the integration; creating a table or changing its structure has to be done directly in Seller Hub.
• French EPR / eco-participation fee: producer-responsibility data for in-scope categories is already handled in the legacy integration. It hasn't yet been re-documented as its own capability for the modern integration, so treat it as present today but not yet fully specified going forward.

Order Management

Getting orders

• Orders are pulled automatically and continuously on the modern integration — new orders are picked up and existing orders are kept in sync as they progress. This flow works independently of whether a merchant's listings have migrated, so a merchant can be fully on the new order flow while their listings are still entirely legacy-managed.
• The first run for a newly connected account looks back 90 days; every run after that only pulls what's new or changed since the last successful run, with a built-in overlap so nothing is missed at the edges.
• Orders are only marked as processed once a full batch succeeds — if part of a batch fails, the whole batch is retried on the next run rather than silently skipped.
• A detailed tax/fee breakdown (VAT, marketplace VAT, sales tax) is captured on every order, which EU/UK sellers in particular rely on.

Order information we store

For every order, Pentagon Connect stores:

• Marketplace order ID, order status (derived from eBay's own fulfilment and payment status together), currency, created date
• Buyer user ID and buyer email
• Billing details: name, phone number, company, country, state/province, street (2 lines), postal code. Note: eBay itself stops returning full billing name, address lines and phone number once an order is more than 90 days old — that's an eBay limitation, not a gap in Pentagon Connect
• Shipping details: name, phone number, company, country, state/province, street (2 lines), city, postal code
• Payment method, order subtotal, order total, discount code/type/value, shipping cost, marketplace fee, final value fee
• Per line item: SKU, item title, quantity, item price, item shipping cost, discount amount, and variation details (e.g. size/colour) where applicable
• Sales tax and marketplace VAT are tracked as separate figures at both order and line level, so different tax views can be reconciled independently
• Ship-by and deliver-by dates, order type, shipping service, and carrier/tracking number once shipped
• Refunds: only refunds that have actually completed are stored (a pending or failed refund is not); each is captured against its line item with an amount and a reference ID
• A free-text note is kept when eBay attaches one to a cancellation or refund, but eBay doesn't return this as a fixed set of codes — it's a working note, not a picklist Pentagon Connect controls (see Return & Refund Reason Codes below)

Shipping orders

• Once an order is ready, Pentagon Connect sends carrier and tracking details to eBay and marks it shipped.
• Partial shipment is supported. An order shipped in multiple packages sends one shipment update per package, each carrying only the items in that package.
• Carrier codes must be mapped. Unlike some other marketplaces, eBay only accepts its own fixed set of carrier codes on a shipment — a free-text carrier name is not accepted. Every internal carrier used has to be mapped to eBay's equivalent first (see Carriers Supported below), or that shipment fails locally and is never sent to eBay, with the unmapped carrier named in the error.
• Shipping rate tables (see Pricing & Stock Sync) feed the shipping cost shown on a fulfilment policy but aren't part of the per-order shipping action itself.

Cancellations

• The legacy integration supports order cancellation as part of its existing flow.
• The modern integration's cancellation capability is mapped to eBay's own cancellation API family and is planned, but is flagged as an open decision at time of writing — recommended for the first rework release, not yet committed to it.
• eBay's own cancellation status and reason note are captured read-only on every order regardless of which integration is handling the actual cancellation (see Order information we store above).

Refunds & returns

• The legacy integration already handles refunds through eBay's managed-payments flow.
• The modern integration's refund capability is mapped to eBay's Fulfillment refund action, with EU/UK refunds requiring an extra digital-signature step (already built for the legacy integration and being reused for the rework) — not yet confirmed for the first rework release.
• Returns specifically run through eBay's separate return process (search, decide, issue a return refund). This is mapped as a rework target but not yet confirmed for v1.
• Not documented in the current source material: eBay's own return-policy framework (returns-accepted flag, return period/method, who pays return shipping, and an optional international-returns override) is read and kept in sync as seller configuration, but the specific reason codes a return or refund is raised under aren't captured as a fixed list — see Return & Refund Reason Codes below.

Claims / incidents

Not documented in the current source material — no eBay claims or incident concept equivalent to some other marketplaces' "incident" mechanism was found in the available source documents.

Carriers Supported

Carriers aren't a fixed list Pentagon Connect maintains — on the modern integration they're downloaded live from eBay, per eBay marketplace region (for example, a seller active on both the UK and Germany sites gets two separate carrier lists), and mapped to Pentagon Connect's own carrier records before they can be used for dispatch. A carrier eBay stops returning is left in place rather than removed, since a merchant may already have mapped it. Example carriers seen on a UK account include Evri, Royal Mail and UPS — the live list for any given account and region is the source of truth, not this example. The legacy integration instead used a fixed, manually maintained set of eBay carrier codes rather than a live download.

Return & Refund Reason Codes

Not documented in the current source material. eBay orders carry a free-text cancellation/refund note rather than a fixed set of reason codes in what's captured today, and the available source documents don't include eBay's own return/refund reason list as it would be surfaced to sellers.

Known Limitations

• eBay is actively decommissioning the legacy Trading integration piece by piece. Category lookups are already gone, order-management fields disappeared in January 2024, and the image-upload call the legacy integration depends on shuts down on 30 September 2026. Any merchant still running on legacy carries real break/fix exposure as each piece is withdrawn, independent of Pentagon Connect's own rework timeline.
• Listing migration to the modern model is one-way with no rollback — once a listing is migrated it can never again be revised through the legacy integration by anyone.
• A handful of older listing features freeze permanently at migration (buyer requirements, charity donation, listing-designer templates, certain title/gallery enhancements) and can never be edited again by anyone.
• A seller can still edit price or stock by hand in eBay's own seller tools after migration; those changes don't sync back to Pentagon Connect, so the two can drift silently unless Pentagon Connect is treated as the single source of truth.
• The modern integration only sees listings created or migrated into it — legacy-managed listings are invisible to it, so the legacy product-download path has to keep running in parallel for any merchant not fully migrated.
• Listing/offer lookups on the modern side are done one product at a time, not in bulk — a real latency consideration for merchants with large catalogues.
• Auction-style listings cannot move to the modern model at all and are being dropped entirely, in any form.
• eBay itself is narrowing the cancellation/return API family it offers (several methods were removed in Q1 2026); if that continues, there may be no supported way to do cancellations or returns via API at all — tracked as an ongoing risk requiring regular review.
• Rate tables are only available on 8 marketplaces, and even there only the costs can be updated, not a table's structure.
• Carrier names must be mapped to eBay's fixed list; an unmapped carrier fails dispatch locally rather than reaching eBay.
• Business policies require the seller to be opted into eBay's Business Policies programme; sellers who aren't are skipped for policy sync entirely.
• Sandbox testing has limited fidelity for some order-action and claims flows, which pushes some validation out to the live pilot phase rather than catching it earlier.

Source Materials

This guide was built from Pentagon Connect's eBay integration and rework specification documents covering product and listing management, order retrieval and shipment, business policies, rate tables, courier mapping, and EU/UK product safety requirements.