Two very different things wear the automation label
When sellers compare eBay tools, "API" and "non-API" get used as marketing badges, which hides an architectural fact. API automation means the software calls eBay's documented Sell API endpoints under the eBay Developers Program, after you grant access through eBay's own consent screen. Non-API automation means the software operates the eBay website for you: a browser it controls, signed in with your session cookies, clicking through Seller Hub and submitting the same forms you would.
That difference is not academic. It decides who holds your credentials, what happens when eBay changes its site, whether a failed operation can be retried safely, and what agreement, if any, covers the access. It also decides how failures show up: as a structured error code you can act on, or as a silent no-op you discover weeks later. This guide walks that boundary, and covers the one place where browser automation genuinely is the right tool.
What the official eBay Sell APIs actually cover
The write side of a reselling operation is fully covered by documented endpoints. The Inventory API models your catalogue as SKU-keyed inventory item records; you attach an offer, which carries price, quantity, category, marketplace, and your business policies, and publishing that offer is what creates the live listing. Because every record is keyed by your SKU, the same call can be repeated without creating a second listing, which matters more than it sounds, as we will see below.
The Fulfillment API covers the post-sale half: retrieving orders filtered by creation date, modification date, or fulfillment status, attaching a carrier and tracking number to specific line items via createShippingFulfillment, and issuing full or partial refunds. Between those two APIs, everything an operator needs to write to eBay, from first publish to final tracking upload, has an official, versioned interface.
Access works through OAuth's authorization code grant. The seller signs in on eBay's own page, reviews the scopes being requested, and consents; the application receives a short-lived access token, typically valid for two hours, plus a long-lived refresh token to renew it. The application never sees the seller's password, and consent can be withdrawn. Usage is metered too: applications start with a documented default call limit of 5,000 calls per day and can apply for higher limits through eBay's growth check, with a getRateLimits method to monitor consumption. A rate limit sounds like a constraint, but it is really a signature: it tells you the access path is known to eBay, monitored by eBay, and designed to keep working.
What non-API tools actually do, and the four risks that follow
A non-API tool automates the eBay website itself, usually from a server-side browser authenticated with a copy of your session cookies. Four risks follow directly from that mechanic. First, session custody: your logged-in eBay session lives on infrastructure you do not control. There are no scopes, so anything possible in Seller Hub is possible with that session, and the only real revocation is changing your credentials and signing out everywhere.
Second, silent breakage. Screen automation depends on the exact structure of eBay's pages. When eBay ships a UI change, selectors stop matching, and there is no versioned contract or error code to tell the tool its click landed on nothing. Repricing that silently stopped running is worse than repricing that visibly failed. Third, no idempotency: if a form submission times out, the tool cannot know whether it went through, so a retry can create a duplicate listing or a double tracking upload. An Inventory API call keyed by SKU converges on retry; a replayed browser click does not.
Fourth, terms exposure. eBay publishes a developer programme with a licence agreement precisely to define how third-party software may access seller accounts. A tool that drives Seller Hub with harvested cookies operates outside that framework, and it is your account, not the vendor's, that carries the consequences. We look at eBay's published policy expectations in more detail in our eBay dropshipping policy guide.
Where browser automation is the right tool
None of this means browser automation is always wrong; it means it belongs on the read side, in your own browser. Temu offers sellers no product API, and its pages are protected by short-lived, fingerprint-bound tokens minted by the page's own JavaScript. Replay one from a datacenter server and Temu bounces the request to a login wall. The only durable way to read current price, stock, and variant state is inside a real, logged-in session, on the seller's own machine.
That is exactly what a browser-session Temu importer does: it reads a product page you can already see, in a session you own, and sends the evidence to your dashboard. Nothing is written to any marketplace, and no cookies leave your browser. The same mechanic powers supplier price and stock monitoring: rechecks open background tabs in your session, and if Temu asks for a login or shows a challenge, the tool pauses and brings the tab forward for you to clear, rather than advertising a bypass.
The working rule: read in the browser, write through the API
Put the two halves together and you get a clean architectural rule. Reads of dynamic supplier pages, in the seller's own session, on the seller's own machine, are legitimate browser work because there is no API for them and no marketplace state changes. Writes that change marketplace state, publishing, revising, ending, uploading tracking, belong in official API calls executed by durable backend jobs that can be retried, audited, and rate-limit aware.
This is how Airmerce is built. The extension reads Temu and creates a reviewable draft; category, aspect, media, and margin checks run as publish blockers; publishing and order tracking upload go through eBay's Sell APIs under OAuth consent you can withdraw. Deliberately absent: supplier auto-payment, CAPTCHA solving, and any promise of policy immunity. Those absences are the design, not gaps in it.
Questions that expose a vendor's architecture in five minutes
You do not need to read a vendor's codebase to place them on this map. Ask where your eBay credentials live: an OAuth consent screen on ebay.com means API access; a request for your password, your cookies, or a remote browser profile means session custody. Ask what happens when eBay changes Seller Hub: an API-based tool should not care. Ask what a timed-out publish does on retry: "converges on the same SKU" is the right answer, silence is not. Ask how you revoke access on the day you leave.
The same questions separate tools within the dropshipping category, where "non-API" is sometimes sold as a stealth feature rather than disclosed as a risk. If you are weighing a specific vendor, our SaleFreaks comparison applies this lens to a concrete product decision.
Checklist
- Confirm eBay access is granted through eBay's own OAuth consent screen, never by handing over a password or cookies
- Verify that publish, revise, and end-listing operations run through Sell API calls, not Seller Hub scripting
- Ask the vendor what a timed-out publish does on retry: it should converge on the same SKU, not duplicate
- Ask where eBay session material is stored and who can access it, before connecting an account
- Keep supplier-page reading in your own logged-in browser session; never send supplier logins to a remote server
- Prefer tools that pause on supplier login and challenge pages over tools that advertise bypassing them
- Review the third-party application access on your eBay account and revoke tools you no longer use
FAQ
Is non-API eBay automation against eBay's rules?
eBay publishes a developer programme and an API licence agreement to define how third-party software may access seller accounts; cookie-driven Seller Hub automation operates outside that framework. Whether any specific tool triggers enforcement is not knowable in advance, but the account risk sits with you, while the session sits with the vendor.
Does the eBay Sell API cover everything a Temu-to-eBay seller needs?
On the eBay side, yes: inventory records, offers, publishing, orders, tracking upload, and refunds all have documented endpoints. What no eBay API covers is reading supplier pages, which is why the read side of the workflow runs in the seller's own browser session instead.
Why does Airmerce ship a Chrome extension if APIs are safer?
Because the extension only reads. Temu has no product API and gates its pages with browser-minted tokens, so supplier data is captured in your own logged-in session. Every write to eBay, publishing, revising, tracking, goes through the official Sell APIs after OAuth consent.
What does idempotency mean for a seller in practice?
It means a retried operation converges instead of duplicating. Inventory API calls are keyed by your SKU, so repeating a publish after a timeout cannot create a second listing. A replayed browser click has no such key, which is how screen-automation tools double-list and double-ship.
Sources
Next paths
Keep moving through the workflow.
Use these Airmerce pages to connect this guide to the importer, monitoring, research, pricing, and fulfillment parts of the Temu-to-eBay workflow.