A reseller's inventory dashboard needs to do more than put a comparable price beside every SKU. Two identical items can have different acquisition costs, repair bills, and time on the shelf. The same market observation can therefore lead to different decisions for each unit you own.
This guide builds a pricing review queue around SoldFetch listing observations and your own inventory records. The application proposes which items deserve attention, explains the evidence and cost policy, and asks an operator to approve any change. All inventory, amounts, and thresholds below are synthetic examples.
Keep inventory ownership separate from comparable identity
Give every owned unit a stable SKU. Store its acquisition date, landed acquisition cost, current asking price, condition, marketplace, currency, and record version. Define landed acquisition cost consistently; this example includes purchase and inbound freight but keeps later selling costs separate.
Map each SKU to an application-owned comparable cohort. A cohort identifies the product, condition and bundle rules used to review listing candidates. Several owned units can share one cohort without sharing acquisition cost or inventory age.
{
"sku": "AUDIO-001",
"version": 4,
"cohortId": "headphones-model-a-used-complete-us-v1",
"currency": "USD",
"landedCost": "90.00",
"currentAskingPrice": "185.00",
"policyVersion": "inventory-policy-v1"
}
These fields belong to your application. sku, cohortId, cost figures, and policy versions are not SoldFetch request parameters. Keep the original inventory condition description alongside any normalized mapping. Hold a unit for review if its accessories or functionality differ from the cohort.
Collect one reviewed snapshot for each cohort
Start with the capabilities response, then request a bounded candidate sample from your server. Keep the API key outside browser code:
curl --fail-with-body --get 'https://soldfetch.com/v1/scrape' \
--data-urlencode 'keyword=sony wh-1000xm5 headphones' \
--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 keyword is an illustrative query, not the fictional cohort's valuation. exactMatch=true excludes explicitly marked loose matches; it does not verify model identity, condition, or bundle contents. Review candidates before including them. The electronics matching guide explains that process in detail.
Preserve itemId, url, soldPrice, soldCurrency, scrapedAt, quality fields, and response warnings. Deduplicate marketplace/item-ID pairs, require the intended currency, and exclude range_lower_bound amounts from a single-price summary. Keep item-only and price-plus-shipping comparisons separate; unknown shipping remains unknown.
Persist an immutable snapshot ID with its reviewed membership, policy version, source retrieval times, and collection outcome. A failed or partial refresh must not replace the last complete snapshot. Displayed listing prices are not verified accepted-offer amounts, and source-reported sale dates remain unverified. A bounded search is a sample rather than a complete sales census.
Calculate your merchant floor explicitly
A comparable median and a merchant's acceptable price answer different questions. The median describes the reviewed observations. The merchant floor expresses your own cost and profit policy.
For this example, the selling fee is a fraction of the proposed item price. Fixed selling costs include outbound shipping and handling, and target profit is a fixed amount:
merchant floor =
(landed acquisition cost + fixed selling costs + target profit)
/ (1 - selling fee rate)
With USD 90 acquisition cost, USD 15 fixed costs, USD 25 target profit, and a 10% fee assumption, the floor is USD 144.45 after rounding upward to the cent. Upward rounding preserves the minimum in this simplified model.
These assumptions are your inputs, not fees returned by SoldFetch. Adapt the formula to your actual channel charges and tax treatment, and avoid counting the same expense twice. Missing costs should hold the SKU for review. Treating them as zero would make an incomplete record look profitable.
If the reviewed median is USD 130, the model has a conflict: that observation is below the USD 144.45 policy floor. Show both figures and request a decision about costs, matching, or profit expectations. Automatically raising the suggestion to the floor would hide that conflict; automatically selling below it would bypass the policy.
Give missing and stale evidence their own states
A useful dashboard needs explicit states for no snapshot, an insufficient reviewed sample, stale evidence, invalid inventory inputs, a floor conflict, and a reviewable price change. None should appear as a zero valuation.
The companion uses at least four accepted observations and a maximum evidence age of seven days. Those are illustrative application policies, not guarantees of statistical reliability or SoldFetch service freshness. Set your own thresholds and retain the version that produced each proposal.
Measure evidence age from its source retrieval time. Recalculating a median today does not make old observations fresh. Keep failed-refresh status visible beside the last successful snapshot, and withhold actionable proposals when that snapshot exceeds your freshness policy.
An operator might see this synthetic queue, with all amounts in USD:
| SKU | Current asking | Reviewed median | Merchant floor | Queue state |
|---|---|---|---|---|
| AUDIO-001 | 185.00 | 160.00 | 144.45 | Review: 100 days held; 25.00 difference |
| CAM-002 | 175.00 | 130.00 | 144.45 | Hold: median below policy floor |
| LENS-003 | 120.00 | Withheld | 100.00 | Hold: two accepted observations |
| GAME-004 | 60.00 | Unavailable | 44.45 | Hold: no snapshot |
| CTRL-005 | 80.00 | Withheld | 55.56 | Hold: evidence is 20 days old |
Prioritize held items and aging stock without making a priority score look like predicted revenue. Inventory age describes your unit's time in stock. It does not establish market liquidity or the probability of a future sale.
Run the offline review-queue example
Download the complete Python example. It uses only the standard library, makes no network requests, and prints the five rows above:
python3 resale-inventory-pricing-dashboard.py
The script uses Decimal for amounts, validates costs and timezone-aware dates, and calculates a median only after evidence passes the stated gates. Its input snapshots contain amounts already accepted by your matching workflow, with observedAt set to the oldest included source retrieval time; the script does not certify raw search results.
For actionable differences of at least USD 10, it emits a proposed item price and the expected SKU version, evidence ID, and policy version. The USD 10 threshold is another example merchant rule. It also flags sufficiently old stock for inspection when a large price difference is absent. No function sends a price update to a marketplace.
The included checks exercise missing, sparse and stale evidence, below-floor medians, invalid costs and dates, tampered prices, expired approvals, and version conflicts. Use the bulk-search tutorial for collection jobs and the price-tracking tutorial for durable refresh history.
Approve a proposal against current records
Save an immutable proposal in trusted server-side storage with the original asking price, proposed amount, reason, snapshot ID, policy version, creation time, expiry, and expected inventory version. The browser submits only its proposal ID and approval intent; the server loads the stored record. Show supporting links and cost assumptions when the operator opens it.
At approval time, load the current SKU and full evidence snapshot from your server, then re-evaluate the sample, freshness, median, cost floor, and merchant rules. Reject changed versions, changed amounts, blocked evidence, and expired proposals. Use the recomputed price only when it matches the stored proposal. Expire proposals before their evidence becomes stale. In a database, perform these checks and the approved update atomically, then append an audit record containing the operator and before/after amounts. The companion demonstrates these guards without implementing authentication, storage, or marketplace writes.
Keep approval and publication status separate. If a later channel update fails, retain that failure for reconciliation rather than reporting the proposed amount as the live listing price.
Share refreshes and pilot a small inventory set
Schedule research by distinct cohort, not by SKU or dashboard visit. Fifty owned units sharing one cohort can reuse one reviewed snapshot while retaining fifty different cost records. Budget successful pages and selected item lookups separately; authenticated cache hits still consume units. Use shared workspace rate and concurrency controls, and consult current pricing and dashboard Billing for available limits.
A paid SoldFetch plan permits transformed dashboards and a small selection of linked supporting listings under Terms section 9.2. Your application must add material analysis or presentation, respect third-party content rights, and avoid raw API passthrough or bulk redistribution.
Start with a small set of owned SKUs, inspect each cohort mapping, and compare proposals with an operator's decision. For related product workflows, see the collectibles valuation app, trade-in quote tool, and marketplace price suggestions guides. Create an API key once the offline queue represents decisions your team can explain.
