Reference · built on requestConnectorCommerce & orders

eBay

Orders, shipping fulfillments, payment disputes, and SKU inventory from an eBay seller account through the Sell APIs.

Request accessPricing ↗

About

eBay is an online marketplace. Its Sell APIs sit under api.ebay.com/sell/{api}/v1 and take an OAuth 2.0 user token minted with the authorization code grant. The Fulfillment API holds orders that completed checkout, the shipping fulfillments recorded against them, and payment disputes. The Inventory API holds inventory items by SKU, offers, and merchant locations. The Notification API delivers topic subscriptions to an endpoint you register.

An operator on Fibric reads orders from the last 90 days, proposes a shipping fulfillment with tracking, a refund, or evidence on a dispute, and waits for your approval. Each action leaves a receipt: what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from eBay and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Orders by creation date, modification date, or fulfillment status through GET /sell/fulfillment/v1/order, 90 days by default
  • Buyer, line items, packaging plans, payment status, and shipping status on each Order
  • Shipping fulfillments already recorded through GET /order/{orderId}/shipping_fulfillment
  • Payment disputes and their activity through getPaymentDispute and getPaymentDisputeSummaries
  • Inventory items by SKU, inventory item groups, offers, and merchant locations through the Inventory API
  • Notification topics subscribed through the Notification API and delivered to your destination endpoint

Proposed actions

  • Target capability: propose a shipping fulfillment with POST /order/{orderId}/shipping_fulfillment
  • Target capability: propose a refund with POST /order/{order_id}/issue_refund
  • Target capability: propose accepting or contesting a payment dispute and adding evidence
  • Target capability: propose a price or quantity change with POST /bulk_update_price_quantity

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Close the loop on every shipped parcel

    When the label prints, propose a shipping fulfillment with the tracking number so the buyer and eBay's seller standards both see it on time.

    With Tracking Sync, Promise Date

  • Answer a payment dispute with the evidence already on file

    Pull the order, the fulfillment, and the carrier's delivery scan, then propose contesting the dispute with that evidence attached.

    With Chargeback Evidence, Delivery Dispute

  • Refund fast, but only after a look

    Read the order and the return, propose issue_refund for the right amount, and record who approved it.

    With Returns Triage, Refund Policy

  • Keep eBay quantity honest across channels

    Compare inventory item quantities with the warehouse and propose bulk_update_price_quantity before an oversell.

    With Oversell Watch, Channel Allocation

Requirements

  • An eBay Developers Program account with a Production keyset and an RuName for the consent redirect
  • The seller's consent to the scopes the keyset requests, including sell.fulfillment
  • Sandbox testing first: the same methods run against apiz.sandbox.ebay.com
  • A Marketplace ID such as EBAY_US or EBAY_GB for each site the seller lists on
Authentication
OAuth 2.0 user access tokens from the authorization code grant, minted with scopes such as https://api.ebay.com/oauth/api_scope/sell.fulfillment and renewed with the account's refresh token.

Limits

  • Default call limits: the order resource allows 100,000 calls per day; payment dispute methods 250,000; the Inventory API 2 million
  • getOrders returns orders from the last 90 days by default and excludes purchases still awaiting payment
  • User access tokens are short lived; when the refresh token expires the seller must consent again
  • Higher limits go through eBay's Application Growth Check

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request eBay ↗

Questions and answers

Which orders does the Fulfillment API return?
Orders that completed checkout. getOrders searches by creation date, last modification date, or fulfillment status, or by a list of orderIds, and returns the last 90 days when no filter is set. Pending-payment purchases that need upfront payment are excluded. Use getOrder for the full cancelRequests array.
What token does the connector need?
A User access token from the authorization code grant, because orders and fulfillments belong to one seller. The token must carry the scopes each method lists, for example https://api.ebay.com/oauth/api_scope/sell.fulfillment for getOrders. Application tokens from the client credentials grant only cover data that is not user specific.
How many calls a day are allowed?
By default, the Fulfillment API order resource allows 100,000 calls per day across its methods; getPaymentDispute and getPaymentDisputeSummaries allow 250,000 each; the Inventory API allows 2 million. These defaults suit smaller sellers; higher limits go through eBay's Application Growth Check.
Ask about eBay

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with eBay through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy