The first version made drafts. The harder work was deciding what could be trusted.
The tool starts with an item’s evidence folder, reads visible facts, narrows noisy sold comps, prepares the listing, and gives the operator an editable review. The production eBay path creates a draft. A final comparison stops approved values from changing before the eBay API call.
maximum strong comps kept for pricing
After identity and condition scoring
conservative price base
Before condition adjustments
maximum eBay title characters
Validated before approval
current production eBay output
Final live publication remains human
The listing begins with the evidence folder from Photo Upload.
The folder contains the item photos, optional video, specs evidence, and the condition details the listing needs. The tool puts the main image first, the home-screen image second when present, and uses a deterministic order for the rest.
Vision reads the images at high detail. Focused passes can reread a sticky note or battery report. The prompt requires visible evidence, source labels, and null when the value is unclear. It cannot infer screen size from resolution or guess a product generation from appearance.
The source photo stays attached to each fact through approval.
Each extracted fact keeps its source photo. Conflicts are resolved by evidence strength, agreement, and the kind of source. A second model can review the proposed listing, but it cannot overwrite verified evidence.
The operator can edit specs, title, description, condition, item specifics, price, shipping, and return settings. Approval creates a canonical snapshot and hash. Immediately before posting, the app compares the outbound values with that snapshot. Drift blocks the request.
- 01
Read visible evidence
Photos produce candidate specs, condition facts, and source labels. Unclear fields stay empty.
- 02
Research sold items
The app searches sold evidence, scores identity and condition similarity, removes likely parts/accessory mismatches, and keeps the strongest set.
- 03
Prepare the draft
Category-specific rules build the title, description, condition, item specifics, price, minimum offer, and policy choices.
- 04
Review and approve
The operator edits the proposal and resolves blockers. Approval freezes the protected outbound fields.
- 05
Create the marketplace draft
The current production eBay path uploads media and creates a draft. A successful source folder is renamed with “- Listed.”
A sold-comps API is only useful after the bad matches are removed.
RapidAPI often returned a mix of the right product, accessories, parts, wrong configurations, and loosely related results. I asked the system to use the 10–15 closest matches and price from the 25th percentile.
The current scoring looks for full and compact model matches, meaningful model tokens, CPU, RAM, storage, generation, form factor, and condition. It penalizes parts and accessory mismatches. The app records p25, median, average, minimum, and maximum, then uses p25 as the conservative base before condition adjustments.
When live evidence is missing, the tool can fall back to an approved past decision or a heuristic. The page does not hide that distinction.
Storage Capacity looked filled in. eBay still rejected the listing.
An iPhone 11 Pro Max repeatedly failed with “The item specific Storage Capacity is missing.” The UI showed both storage and capacity. The offer existed, but eBay rejected publication.
The review screen and the outbound payload disagreed. Follow-up changes added the phone-specific Storage Capacity field, preserved approved item specifics during posting, and normalized mobile storage in one place before posting.
The final validation checks the outbound payload because the review screen can be right while the marketplace payload is wrong.
The app keeps the failed item instead of turning it back into a mystery.
Dry run supports safe testing. Interactive review keeps approval with the operator. Experimental autopilot checks deterministic blockers such as missing identity, weak screen-size proof, a no-drive contradiction, invalid price, unresolved shipping, and low sold-comp evidence. Items that fail become exceptions.
The app can resume compatible items after an interrupted run. When posting fails, it keeps the reason and an audit record. SKU conflicts have an explicit recreation path. Manual corrections enter a learning queue for review instead of becoming invisible universal rules.
- Approved title, price, condition, category, SKU, item specifics, shipping, description, and policy fields are protected.
- A low-proof item can stop without losing the work already completed.
- Pricing memory stores approved decisions and can suggest one when live pricing is absent.
- The source folder name becomes part of queue state after a successful draft.
The app assembles the repetitive parts. A minutes-per-listing claim still needs a timed comparison.
The app assembles visible specs, an 80-character title, condition copy, item specifics, sold-comp pricing, minimum offer, shipping, media, and the marketplace draft. Resume avoids rebuilding a compatible item after an interruption.
I have not timed enough comparable manual and assisted listings to publish minutes saved. A laptop, phone, and oddball piece of equipment do not have the same review burden.
Here is what remains unmeasured or unresolved.
- The current production eBay path creates a draft, not a final live listing.
- Autopilot remains explicitly experimental.
- Vision and OCR can miss or contradict evidence.
- Marketplace APIs can reject a payload that looked correct in the UI.
- Some pricing falls back to memory or heuristics when live comps are unavailable.
- Current production volume, extraction accuracy, exception rate, rejection rate, revenue impact, and minutes saved are unknown.