A seller creating a listing often needs help choosing an asking price. A useful marketplace feature can show a small set of comparable observations, explain a descriptive range, and let the seller decide. That decision belongs inside the listing workflow: the suggested amount should reflect the item currently being described and require the seller's approval before it becomes their asking price.
This guide designs that feature for one seller and one listing draft. The fictional product and amounts below are synthetic; they do not describe a customer or current market prices. SoldFetch supplies listing evidence. Your application owns product matching, the suggestion policy, the seller's choice, and publication.
Capture an identity before requesting a suggestion
Give the draft a structured identity alongside its editable title. For a fictional Northstar C2 camera, collect maker, model, variant, and bundle contents. Record condition separately: a working used body is a different comparison target from a repair project or a lens kit.
The following fields belong to your application:
{
"listingId": "draft-camera-7",
"revision": 3,
"identity": {
"maker": "Northstar",
"model": "C2",
"variant": "standard",
"bundle": "body only"
},
"conditionPolicy": "working-used",
"ebaySite": "ebay.com",
"currency": "USD",
"priceBasis": "displayed_item_amount"
}
Require a new revision whenever a relevant field changes. Missing identity should produce a request for more information. Silently widening the query to compensate can create a suggestion for a different product.
Neither these identity fields nor conditionPolicy are native SoldFetch filters. Translate the identity into supported search terms, then use your own review layer to decide which candidates qualify. The electronics matching guide explains that review in detail.
Fetch a bounded candidate sample from your server
Check capabilities for data availability and supported marketplaces. Keep SOLDFETCH_API_KEY on your backend. A listing form should call your authenticated suggestion route, which checks ownership of the draft before contacting SoldFetch.
This example query illustrates the supported request shape; the product name is fictional and may return no results:
curl --fail-with-body --get 'https://soldfetch.com/v1/scrape' \
--data-urlencode 'keyword=Northstar C2 camera body only' \
--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"
exactMatch=true removes explicitly flagged loose matches; it does not verify exact product identity. Keep a finite page budget and deduplicate marketplace/item-ID pairs. Do not interpret the requested count as a promise of that many usable comps.
Store the response, request context, retrieval timestamps, and warnings on your server. Add separate review fields for identity, condition policy, decision, and reasons. Review ambiguous bundles or variants before accepting them. The Search API reference documents the returned fields; your review metadata is an additional application layer.
Turn reviewed evidence into an explainable suggestion
Define the amount basis before calculating anything. Here it is displayed item amounts in USD, excluding shipping. Keep unknown shipping unknown. Accept only sold-search rows with the intended currency and quality.priceBasis=displayed_listing_price; a range lower bound does not represent one camera's price.
In this synthetic example, five accepted observations contain displayed amounts of $80, $90, $100, $110, and $120. Their median is $100. Inclusive quartiles give a central observed band of $90–$110. The companion uses statistics.quantiles(..., method="inclusive") with Decimal amounts so the calculation is reproducible.
That band describes the reviewed sample. It is not a confidence interval, a forecast of what this seller will receive, or proof that every comparable is interchangeable. Explain the inclusion policy and observation count beside it. The sold-versus-asking guide covers why displayed sold-search amounts and a seller's chosen asking price answer different questions.
Use a display such as:
| Seller sees | Example content |
|---|---|
| Comparable-price context | $90–$110 USD; median $100 |
| Basis | Five reviewed displayed item amounts; body only; working used |
| Evidence age | Oldest included source observation: October 27, 2026, 15:00 UTC |
| Supporting examples | A small selection of linked eBay listings |
| Your asking price | Editable amount, initially blank |
| Action | Use $100, enter another amount, or continue without a suggestion |
Keep the seller's editable field blank until they choose an action. An invisible default can turn a research aid into an accidental pricing decision.
Make sparse and stale results ordinary states
Choose a minimum reviewed count and an acceptable evidence age for your product. The offline example requires five observations and allows evidence up to 24 hours old; these are demonstration policies, not SoldFetch guarantees or universal defaults.
Check source timestamps as well as when your server received the response. A cache hit can contain older evidence. Preserve both the response's fetchedAt and each listing's scrapedAt; repeated retrievals of the same listing should not increase the sample count.
If too few rows qualify, show “Not enough comparable evidence” and let the seller enter a price. If the evidence is too old, offer a refresh when appropriate and identify the last usable snapshot. A failed request should leave the draft and any seller-entered amount intact. Never replace a missing suggestion with zero or broaden condition rules automatically.
Displayed prices are not independently verified final payments or accepted-offer amounts. Source-reported dates are not verified sale dates. Keep those limitations available with the suggestion rather than presenting a recent response as a complete record of recent transactions.
Bind approval to the current draft
Save an immutable suggestion snapshot containing its policy version, creation and expiry times, draft fingerprint, included count, calculation basis, and references to supporting evidence. Expire it no later than the oldest included observation's permitted age. The fingerprint should cover the draft ID, revision, identity, condition policy, marketplace, currency, and amount basis.
When the seller clicks Use $100, the server should load the saved snapshot and current draft, verify ownership, and compare the fingerprint again. A seller who added a lens after generating a body-only suggestion must receive a fresh review, even if an old browser tab still displays the earlier button.
Record the snapshot ID and the exact amount the seller approved. Allow an explicit override: an asking price of $125 may be the seller's deliberate choice. Label it as seller-entered and retain the comparison context. A suggestion does not authorize automatic publication; the marketplace's normal review and publish flow still applies. Apply the final update atomically against the checked draft revision.
Try the complete offline example
Download the Python companion and run:
PYTHONDONTWRITEBYTECODE=1 python3 resale-marketplace-price-suggestions.py
It makes no network requests and needs only the standard library. It builds the synthetic $90–$110 snapshot, records an explicit $125 seller override, and checks changed drafts, duplicate IDs, mismatched identity, sparse evidence, stale evidence, and expired approval. Its approval helper demonstrates validation; your backend must add authentication, storage, and an atomic revision check.
Under SoldFetch Terms §9.2, a paid plan permits derived results in paid or freemium apps, including their free-tier users, subject to the stated conditions. Small supporting listing selections need corresponding eBay links. Add material analysis or presentation, protect credentials, and respect third-party content rights; the permission does not grant rights to listing images or trademarks.
For related product workflows, see the collectibles valuation app, electronics trade-in quote tool, and resale inventory dashboard. Keep this feature focused on helping one seller make and approve one listing decision.
