A search for a used phone can return complete devices, replacement screens, carrier-locked variants, repair projects, and bundles. They may share a model name while representing very different products. Averaging those prices creates a precise number for an imprecise question.
A useful electronics-comp workflow starts with a product definition and ends with a reviewable sample. SoldFetch supplies listing observations and quality metadata. Your application must decide which observations belong together, preserve uncertainty, and make the inclusion decisions visible.
This tutorial uses a phone cohort to demonstrate the method. Every amount and sample record in its runnable example is synthetic. The example does not measure current phone prices or provide a resale valuation.
Define the device you want to compare
Write the target product in more detail than you would type into a search bar. For a phone, the important attributes may include model generation, storage, carrier status, functionality, battery information, and included accessories. For a GPU, they might include chip model, memory size, board variant, cooling assembly, and whether the card is functional.
Here is a local review policy for a phone example:
| Attribute | Inclusion rule |
|---|---|
| Model | The intended generation and model; no Plus, Pro, or Max variants |
| Storage | One selected capacity |
| Carrier | Explicitly unlocked; unresolved claims held for review |
| Functionality | Working complete handset; no activation locks or repair-only listings |
| Condition | Used; cosmetic differences recorded for review |
| Bundle | One handset with the same defined accessory policy |
| Marketplace and currency | ebay.com, USD |
| Amount | Single displayed item price, excluding shipping |
Choose the accessory policy deliberately. “Handset only” is easier to compare than a mixture of phones, watches, and chargers. If you accept missing cables or ordinary cosmetic variation, document that decision. Do not silently broaden the set when the first search produces few usable candidates.
Retrieve candidates with supported search parameters
Start with a narrow keyword and the broad used-condition filter. Check capabilities for the current data gate and enabled marketplaces before making authenticated calls.
curl --fail-with-body --get 'https://soldfetch.com/v1/scrape' \
--data-urlencode 'keyword=iphone 13 128gb unlocked' \
--data-urlencode 'ebaySite=ebay.com' \
--data-urlencode 'itemCondition=used' \
--data-urlencode 'sold=true' \
--data-urlencode 'exactMatch=true' \
--data-urlencode 'count=60' \
--data-urlencode 'page=1' \
--header "API-KEY: $SOLDFETCH_API_KEY"
The model, capacity, and unlocked wording in this request are search terms. They do not become guaranteed structured filters. Do not add invented parameters such as batteryHealth, carrierUnlocked, or completeDevice to the API request. Apply those detailed requirements in your own review layer.
Save the full response, request parameters, collection time, and warnings. If you retrieve more pages, cap the sweep and stop when a page is empty or contains no new item IDs. A requested count is a ceiling; filtering and deduplication can reduce the rows returned. A limited search is a candidate sample, not an inventory census.
Turn the shortlist into a review queue
Titles can identify obvious accessories and parts, but title matching alone cannot confirm a device. A listing that says “unlocked” might also mention a fault or contradictory details elsewhere. Route uncertain candidates to review rather than turning missing evidence into an automatic pass.
For selected candidates, use /v1/item/{itemId} to inspect available itemSpecifics, conditionDescription, and images. Some fields can be absent. The item API guide explains the request and its limits. Item enrichment adds evidence; it does not independently certify model identity or functionality.
Keep local review fields separate from the API response. A compact journal might contain itemId, decision, reason, reviewer, reviewedAt, and policyVersion. Use three decisions: include, exclude, and hold. A hold prevents ambiguous items from entering the median while keeping them available for another reviewer.
Do not claim the API verified your conclusion. Search quality metadata marks exactProductMatchVerified=false, including when exactMatch=true was requested. Your review can support an application decision without changing that upstream claim.
Separate condition, functionality, and bundle differences
The word “used” does not resolve every commercially important difference. Cosmetic wear, missing components, functional faults, carrier restrictions, and seller-stated battery health can change the product a buyer receives. Record these independently where evidence is available.
Avoid scoring all those attributes into one opaque “condition grade” too early. A complete device with heavy scratches and a pristine device with an activation lock are not simply adjacent values on the same scale. One may belong in your cohort; the other may require exclusion.
For a first analysis, use strict inclusion rules and an explicit hold queue. Later, if you have enough reviewed observations, split the set into useful subcohorts such as complete working handsets with light versus heavier cosmetic wear. Show how many observations support each group.
Preserve the reasons for rejected rows. Common examples include wrong generation, wrong storage, parts only, lot of multiple devices, missing key information, and unresolved carrier status. These counts reveal whether your search query or product definition needs refinement.
Choose amounts after reviewing products
For sold-search rows, soldPrice is a displayed listing amount. It is not a verified accepted-offer payment. Keep quality.acceptedOfferAmount, quality.priceBasis, quality.saleDateVerified, and the source timestamp alongside it.
Exclude range_lower_bound observations from a single-price summary. A number extracted from the lower end of a range is not equivalent to one handset's displayed price. Require the intended currency, a finite nonnegative amount, and an explicit include decision.
This tutorial uses item-only prices. If your workflow instead compares item-plus-shipping amounts, define a separate series and require a usable totalPrice. Missing shipping stays unknown. Never replace a null shipping amount with zero, and do not mix item-only and landed amounts in one median.
Deduplicate item IDs within the collection run so a repeated page does not give one listing extra weight. If the same ID appears with conflicting evidence during collection, retain the conflict for review and use one documented observation rule rather than averaging two snapshots of the same listing.
Calculate the median and IQR after review
The companion offline Python example uses only the standard library. It keeps decimal values as Decimal, applies a local review journal, excludes unsupported price bases and currencies, and reports both reviewed count and a reason count for rejected rows. It uses the first observed row per ID; retain conflicting duplicates for review before using that rule in production.
python3 used-electronics-comps.py
Its six accepted synthetic item prices are USD 100, 120, 140, 160, 180, and 200. The median is USD 150. The lower-half median is USD 120; the upper-half median is USD 180; the interquartile range is therefore USD 60.
The script uses the median-of-halves convention and excludes the center value before calculating halves for an odd sample. Other quartile methods can produce different results. State the convention in exported reports, and avoid presenting the IQR as comparable across systems that use different definitions.
An IQR describes spread in this reviewed sample. It is not a confidence interval, a predicted sale range, or proof that every included device is equivalent. The script withholds quartiles below four accepted rows because a spread summary on a tiny set adds little useful context.
Review unusual rows before removing them
A median reduces the influence of extreme amounts, but it does not make bad matches harmless. If a price looks unusual, inspect its source, condition evidence, bundle, currency, and price basis before deciding what to do.
Do not remove a listing solely because its amount is inconvenient. A legitimate observation may be unusual. Record whether an exclusion is based on product mismatch, missing evidence, or a predeclared analysis rule. Keep the original row so someone else can reproduce the decision.
Compare the reviewed sample with the hold and exclude queues. If most candidates fail because the device capacity is unclear, a polished chart is less valuable than improving the evidence. Show “limited comparable sample” when appropriate, and let the user inspect the surviving listings.
Export a defensible comp report
Include the product definition, policy version, marketplace, currency, price basis, accepted count, review counts, median, IQR convention, and observation times. Make source URLs accessible and disclose that accepted-offer amounts and sale dates are unverified.
If you repeat the analysis, use the same policy and collection budget. Preserve runs separately so an incomplete collection cannot look like a sudden market movement. The price-tracking guide covers durable observations and run history.
Create a SoldFetch account and start with one device cohort you can review manually. Consult the Search API reference for supported parameters. Automate the collection and arithmetic first; keep the matching decisions inspectable as the workflow grows.
