eBay API Integration Service: Scope, Limits and 2026 Changes

What an eBay API integration service actually covers

An eBay API integration service connects your own system (a store platform, ERP, warehouse tool or custom back office) to eBay through eBay's official APIs, so listings, stock, orders and shipment data move without anyone re-keying them in Seller Hub. It is engineering plus ongoing maintenance, because the eBay side keeps changing.

Every eBay fact on this page was checked against eBay's developer documentation on September 29, 2026.

A complete scope has six parts:

• Authorization: seller consent, plus OAuth token storage and renewal for every connected eBay account.
• Listing sync: mapping your product data to eBay categories, item specifics, business policies and pictures, then creating and revising listings.
• Inventory and price sync: pushing quantity and price changes out fast enough to avoid overselling.
• Order sync: pulling paid orders in and pushing tracking and fulfillment status back.
• After-sale flows: cancellations, returns, refunds and disputes.
• Operations: rate-limit handling, retry queues, alerting, and tracking eBay's deprecation notices.

The last two are the easiest to leave out of a quote and the ones that decide whether the integration still works a year from now. The sections below cover where each one bites.

Which eBay APIs to build on in 2026

eBay runs two generations of selling APIs side by side. The REST APIs (Inventory, Fulfillment, Account, Metadata, Taxonomy, Media, Notification and Feed) use JSON and OAuth 2.0. The older Trading API is XML-based and still carries calls like AddFixedPriceItem and GetOrders. In practice most production integrations touch both for a while, since eBay's own Inventory API overview lists the Trading API, Account API and Fulfillment API as companions to the Inventory API.

The practical rule: start every new build on the REST APIs. An existing Trading API integration does not need a rewrite this quarter, but every call it depends on should be checked against the deprecation list on a schedule, not once at project start.

eBay API deprecations to plan around in 2026

eBay retires Trading API capability call by call and event by event, not in one big switch-off. The table below is taken from eBay's API deprecation status page and shows what was still scheduled when it was checked.

Already gone in 2026: Trading API GetCategories (April 15), GetCategoryFeatures (June 4) and the ItemMarkedPaid notification (June 22); the Compliance API (March 30); the whole Product API (August 15); and several Post-Order API methods between January and March.

Two patterns matter more than any single date. First, notice windows vary a lot: about a month for the VeRO API, nearly eleven months for UploadSiteHostedPictures. Second, a replacement often splits across two APIs: GetCategories became Taxonomy plus Metadata. An integration that hard-codes one call per job breaks in pieces, and a fix is rarely a one-line swap.

OAuth on eBay: tokens, consent and where integrations break

eBay mints two kinds of OAuth token, and the difference decides your architecture. eBay's authorization guide defines them: application tokens come from the client credentials grant and cover data that is not tied to a seller, such as taxonomy and metadata. User tokens come from the authorization code grant after a seller consents, and they cover anything that touches that seller's listings or orders.

Access tokens last two hours (7,200 seconds in eBay's example responses). The example refresh token in the same guide expires after 47,304,000 seconds, about 18 months. The refresh token is what your database really stores, so treat it like a credential.

What revokes a refresh token

• The seller changes their eBay username or password, which revokes active refresh tokens automatically.
• The seller revokes access from their own eBay account pages.
• eBay revokes it for its own reasons.
• Your app adds a scope. Every seller must consent again, so eBay advises requesting the scopes for current and planned features together.

Design consequences

Treat "seller must reconnect" as a normal state, not an error. The integration should pause that seller's sync, flag it in your UI or by email, and resume after re-consent, rather than retrying failing calls until a limit is hit.

Refresh lazily. eBay's own advice is to renew a token after an invalid-token error rather than tracking each expiry. The arithmetic supports it: refreshing every seller every two hours costs 12 refreshes per seller per day, so the 50,000-per-day refresh limit runs out at roughly 4,000 connected sellers. Add a per-seller lock so parallel workers do not all refresh the same token at once.

If you still call Trading API endpoints with legacy Auth'n'Auth tokens, note that those last 18 months, come with a seven-day expiry warning, and fail with error 932 once hard-expired. eBay recommends OAuth even for the traditional APIs.

Syncing listings and inventory with the Inventory API

The Inventory API models a listing in layers. A seller needs at least one inventory location, then an inventory item (unique SKU per seller), then an offer that references a marketplace, location, category and three business policies. Publishing the offer makes it a live listing. Variations need an inventory item group on top. The call order is createInventoryLocation, createOrReplaceInventoryItem, createOffer, publishOffer.

These are the traps that show up in scoping calls:

• It is a one-way door. eBay's Inventory API overview states that listings created through the Inventory API cannot be edited in Seller Hub or any other listing platform. Decide which system owns listing data before go-live, and tell the sellers' staff.
• Business policies are mandatory. The seller must be opted in, and every offer needs a payment, fulfillment and return policy. Accounts that never opted in fail at the first offer, not at connection time.
• SKUs are identity. The SKU must be unique across that seller's inventory. Your SKU mapping needs to be stable, or a re-import creates duplicates instead of updates.
• Fields become required at publish. Some fields are optional while you build an offer but required to publish, so validate before publishing, not after a failure.
• Existing listings can be migrated, with conditions. bulkMigrateListings converts live listings into Inventory API objects, but only those meeting extra requirements. Budget for the ones that do not.
• Zero stock should not end the listing. With Out-of-Stock Control turned on, a listing at zero quantity stays active for up to 90 days and is hidden from search.

Category rules also move under you. eBay's developer portal has announced that Apparel and Footwear listings with non-standard, missing or incomplete size data may be blocked or hidden from August 2026, and that standardized condition details became required in certain coin categories from May. Keep category-specific rules in configuration, not hard-coded, so a rule change is a data fix instead of a redeploy. eBay's new Inventory Mapping API, which turns existing product data into listing previews, is worth evaluating for the mapping step.

Syncing orders and shipments with the Fulfillment API

In eBay's model an order comes out of checkout, its line items are grouped into packages, and each package's handling and shipping is a fulfillment. Your integration reads orders with getOrders, then writes tracking back with createShippingFulfillment. Fulfillment speed is not cosmetic: eBay's documentation notes that a seller's status depends partly on a record of timely fulfillment.

One documented limit causes false bug reports. The Fulfillment API only includes transactions that completed checkout, and getOrders does not return pending-payment purchases that require upfront payment. If your import count differs from Seller Hub, check for unpaid orders before debugging the sync.

For speed, the Notification API lets you register a destination endpoint and subscribe to topics, so eBay pushes events to you instead of you polling. Do not rely on push alone: run a polling pass with a lookback window as a safety net, and expect the older Trading API notification events to keep disappearing (ItemMarkedPaid is already gone).

Refunds deserve their own test plan. issueRefund sits in the Fulfillment API, and for EU and UK sellers it requires a digital signature (next section).

Call limits, growth checks and compliance requirements

Three eBay requirements shape both the schedule and the budget of an integration, and none of them is visible from a sandbox demo.

Call limits vary by API, so read eBay's published table for the APIs you use. Track consumption with getRateLimits in the Developer Analytics API, and file the Application Growth Check before you approach the ceiling; eBay does not charge for it.

The signature requirement is the most engineering-heavy. It follows IETF RFC 9421 and RFC 9530 and adds four headers (x-ebay-signature-key, Content-Digest when there is a payload, Signature and Signature-Input). Keys come from eBay's Key Management API, and eBay does not store the private key, so a lost key means generating a new pair. To test in the sandbox, the test user's domicile must be set to an EU country or the UK; otherwise signatures are never required or checked.

Build in-house, use a connector, or hire an integration service

There is no universally right answer, and a connector is often the correct first move for a standard catalog. What matters is where your requirements stop fitting one.

If your catalog or workflow has outgrown a connector, a custom build is exactly what Netalith's marketplace integration service covers, including eBay listings, inventory, orders and tracking alongside Amazon SP-API, Walmart, Etsy and other channels.

What to ask an eBay integration provider before you sign

1. Which eBay APIs will it use? Any dependency on a Trading API call from the deprecation list is future rework.
2. Whose developer keyset will it run under? The keyset carries your call limits and Application Growth Check status.
3. How are revoked refresh tokens handled? The answer should describe re-authorization, not retries.
4. Which system owns listing data? Inventory API listings cannot be edited in Seller Hub afterwards.
5. Do pending-payment orders matter to you? The Fulfillment API leaves them out of getOrders.
6. Do you sell to EU or UK buyers through EU or UK sellers? If sellers there are in scope, refunds and finance data need digital signatures.
7. What happens during rate limiting or an eBay outage? Look for queues, backoff and alerts.
8. Who watches eBay's deprecation notices, and is that in the price?
9. What do you get at handover? Source code, documentation, tests and key ownership.

Scoping your eBay integration with Netalith

Send your platform, the eBay flows you need (listings, stock, orders, tracking, refunds) and the markets you sell in, and Netalith will scope the work. Pricing follows scope, not a fixed package. Request a free quote to start.