Market Value Estimates

OneTake can pull a market value estimate from a third-party provider and apply it to a gear item. When you accept an estimate, two things happen together:

1. The item's value fields are updated with the new estimate.
2. The estimate lookup is marked as accepted so it isn't re-offered.

Both steps must succeed for the acceptance to be considered complete. If the second step fails — for example, because of a brief database conflict — OneTake reports the failure rather than recording a false success.

Agreed-value items are skipped entirely

Before OneTake looks at either provider, it checks whether the item is set to the Agreed value depreciation method with a positive amount entered — see Gear Detail → Agreed value supersedes the market lookup. When that's the case, the agreed amount is the item's value, and the market lookup is skipped outright: no provider is queried, and nothing is written to the item's market value fields.

This applies everywhere a market lookup or refresh can run:

• the Market lookup button on the item's own page — already hidden for these items, as described on the Gear Detail page,
• a bulk lookup across several items, where an agreed-value item is reported with a failure_reason of agreed_value instead of a quote, and is excluded from the count of items actually queried,
• the scheduled automatic refresh that keeps market values current, which excludes agreed-value items from its own query rather than fetching a quote for one and then discarding it — and, like bulk accept below, also guards the write itself against an item switching to Agreed value in the gap between that read and the write — see How the scheduled refresh closes the same race below, and
• bulk accept, where an estimate that was already queued for an item before it was switched to Agreed value is reported as skipped — with reason: 'agreed_value' — rather than being applied.

An item set to Agreed value but with no amount entered yet is not affected by any of this. It's treated like any other item — including for market lookups — until a positive amount is saved.

How the scheduled refresh closes the same race

The scheduled refresh reads a batch of items whose market value is due for a check, then shortly after writes a fresh quote back to each one. If you switch an item to Agreed value with a positive amount in the gap between those two steps, the write that would apply the refreshed market value doesn't take effect — the same condition that excludes agreed-value items from the batch's read is also attached to the write itself, so the write only succeeds on a row that still qualifies at the exact moment it runs.

When the guarded write matches no row, OneTake can't immediately tell whether that happened because the item switched to Agreed value, or because the item was deleted in that same gap between the read and the write. It checks once more, against the item's own record, to tell the two apart:

• The item still exists. This is the agreed-value race: the item is left with its agreed amount, isn't counted as refreshed, and isn't reported as an error. It's tracked as a routine agreed-value skip.
• The item no longer exists. There's nothing left to apply a value to. This is tracked separately, under its own not-found skip count — also not counted as refreshed and not reported as an error, since a deleted item racing the refresh isn't a failure either.

Either way, since nothing was actually applied to the item, no entry is written to the audit log for it.

If the follow-up existence check itself fails — for example, a transient database error — OneTake doesn't guess which of the two outcomes applies. That item is recorded as an error in the run's results instead of being silently counted as either kind of skip.

How OneTake picks a source

This section covers items without an effective agreed value — see Agreed-value items are skipped entirely above for those.

OneTake checks Reverb first. When Reverb's estimate is backed by enough active listings, OneTake uses that estimate directly. Otherwise, it also checks eBay and uses whichever of the two is the stronger estimate.

This cascade — Reverb first, eBay only as a fallback, one winning quote — is what drives bulk market-value lookups and automatic value refreshes. There, you see one market value and one source.

When you run a lookup yourself from an item's Insurance card, OneTake instead checks both providers and, when both have a usable quote, lets you choose between them. See Comparing Reverb and eBay below.

Both Reverb and eBay currently report asking prices from active listings, not sold prices. See Gear Detail → Insurance card for how the source is described on an item's page.

Comparing Reverb and eBay

Selecting Market lookup on an item's Insurance card checks both Reverb and eBay, rather than stopping at the first one with a usable quote.

• Only one provider has a usable quote — you see just that one. The preview looks the same as any single-provider result, including the explanatory note described in When eBay supplies the value instead of Reverb below, when it was eBay that came through.
• Both providers have a usable quote — the preview shows both side by side, each card naming its source, its median value, and how many listings it's based on. Reverb's quote, when available, is listed first and selected by default.
• Pick whichever quote you'd rather use, then select Accept. Only the quote you accept is applied to the item — the other is discarded, not saved anywhere.
• Whichever quote is shown or selected carries its own link-back and usage note beneath it in the preview — Reverb's required API-terms notice and listing link, or eBay's listing link and OneTake's own neutral note: "Asking prices from active eBay listings. Not affiliated with eBay." When you're comparing both quotes, the link and note shown track your current selection: picking eBay's quote swaps the attribution from Reverb's to eBay's, and picking Reverb's swaps it back.

This comparison only happens for the Market lookup button on an item's own page. Bulk market-value lookups and automatic value refreshes still use the single cascade described above, and never show you a choice.

If your account has a limit on how many market lookups you can run in a day, comparing both providers at once still counts as a single lookup against that limit — checking two providers doesn't cost double.

When eBay supplies the value instead of Reverb

Because OneTake checks Reverb first, an estimate that ends up sourced from eBay means Reverb was tried and didn't produce a usable number. When that happens, the market value preview adds a short note explaining why — so it reads as "we checked, and here's what happened," not as Reverb being skipped silently.

This note appears only when the preview is showing a single quote — in a comparison that found a usable quote from both providers, there's no fallback to explain, since you're shown both directly.

The note's wording depends on what happened with Reverb:

No note appears when Reverb wasn't checked at all — for example, because it isn't configured for lookups on this account — or when Reverb is itself the source of the value shown.

When neither provider has a usable number

If OneTake can't produce any usable estimate, the message you see depends on why:

• If eBay came back with nothing and Reverb specifically couldn't be reached — rather than Reverb simply finding no listings — the message says so directly: "We couldn't reach Reverb and eBay had no matching listings."
• For a "not enough listings to estimate" or a "prices vary too much to estimate" result (see the ambiguous-model message below), when Reverb specifically couldn't be reached, OneTake adds a line to that message: "We also couldn't reach Reverb just now, so this only reflects eBay." This only appears when Reverb was actually unreachable — a Reverb attempt that was reachable but simply found nothing useful doesn't add this line.
• Otherwise, you see the ordinary version of that message on its own, with no mention of Reverb's reachability.
• If no provider could be reached at all, you see: "Market lookup is not available at the moment. Please try again later." This points to something on OneTake's side rather than anything about your item or account — it's logged for OneTake to investigate, not something you need to act on.

Keeping Reverb's estimate on-target

Reverb's search matches on title text across every category, so a plain search for an instrument can also turn up parts and accessories that happen to share its name — a pickguard or wiring harness listed as "Fender Telecaster," for example. Before OneTake works out a price from Reverb's results, it sets aside listings that don't actually look like your item:

• Parts and accessories are excluded. A listing filed under Reverb's Parts or Accessories categories is dropped before pricing, since those never represent the value of a whole instrument.
• Listings from a different maker are excluded. A listing's maker has to plausibly match your item's manufacturer — for example, a search for "MusicMan" accepts a listing made by "Ernie Ball Music Man" but not one made by "Sterling."
• Mislabeled parts listings are excluded too. Some parts sellers paste the whole product title — model name included — into the maker field, and file the listing under the instrument's own category. OneTake catches these and drops them even though the category check alone would have missed them.

Listings with no maker or category recorded at all are kept rather than excluded — OneTake only filters out what it can actually check.

If every listing for a search gets filtered out this way, Reverb reports that it found no usable listings, and OneTake moves on to check eBay instead.

Items with only a manufacturer recorded

When an item has a manufacturer but no model recorded, OneTake first tries to fill in a model from the item's name before giving up. For example, an item named "APOGEE JAM" with manufacturer "Apogee" and no model derives a model of "JAM", and OneTake searches "Apogee JAM" as a normal query — it no longer treats every manufacturer-only record as unsearchable.

Deriving the model strips the manufacturer's own name out of the item name — including a trailing possessive like "Apogee's" — wherever it appears as a whole word, and keeps whatever's left. "Vintage Apogee Jam" derives "Vintage Jam"; "Fender Tele / Fender" derives "Tele". A manufacturer name that only appears as part of a longer word is left alone — a manufacturer of "Line" does not touch "Line6 Helix".

Only when the name adds nothing beyond the manufacturer's own name does OneTake still treat the item as manufacturer-only — for example, a blank name, a name that matches the manufacturer exactly, or a name made up entirely of words that are already part of the manufacturer's name (so a manufacturer of "Ernie Ball Music Man" with a name of just "Music Man" derives nothing extra). In that case, a search on the manufacturer name alone is too broad to price reliably — it would return a price for the whole brand's catalogue rather than this specific item. Both Reverb and eBay skip the search entirely in this situation and answer as if nothing was found, rather than returning a confident-looking price for the wrong thing.

How OneTake cleans the comparable sample

Before averaging listings into a price, OneTake also screens the sample itself — on top of the parts/accessory and maker checks described above — so a handful of mismatched listings can't skew what your gear is priced at. This applies on both Reverb and eBay.

Used listings are priced first, not new stock

OneTake prices your gear against what a used example is asking for, not what a dealer charges for the same thing brand new — a brand-new $439 microphone isn't what your used one is worth. Both the Reverb and eBay searches ask for used listings first.

If there are fewer than three usable used listings, OneTake automatically widens the search to include new stock too, so thinly-listed gear still gets a quote rather than none at all — a new-stock asking price beats no answer.

When that wider search is needed, OneTake merges it with the used listings it already found rather than starting over, so no used listing already found is lost to double-counting. If the wider search fails for some reason, OneTake still prices the smaller used sample rather than giving up on an estimate entirely.

On eBay, listings marked "For parts or not working" are excluded from the sample outright, regardless of whether OneTake is searching used or new listings — the same spirit as Reverb's parts/accessories category exclusion described above.

Matched pairs, sets, bundles, and multi-packs are excluded

A listing that prices more than one unit — a matched stereo pair, a set of three, a 10-pack, "2x" in the title — is dropped from the sample on both Reverb and eBay, so your single item is never priced against the cost of several at once.

Vintage listings are excluded from a modern item's price (Reverb only)

When OneTake has identified your item as current production rather than vintage, it also drops Reverb listings whose stated build year is old enough to count as vintage by OneTake's own cutoff — so a decades-old example doesn't get averaged into a current item's price. A listing with no year recorded, or one with an unclear year (for example, a reissue listed as "1965 Reissue"), is kept rather than guessed at.

Vintage gear is priced against gear from its own era (Reverb only)

When your item's year marks it as vintage, Reverb doesn't just exclude recent production — it narrows the search to a window of years around the item's own year, so a 1978 U87 is priced against other listings from around 1978, not lumped together with every vintage U87 from the 1960s through the 1980s.

• The window reaches 5 years either side of the item's year.
• The window is capped so it never reaches into the modern-production cutoff — OneTake's own vintage/modern dividing line — even for an item right at the edge of being vintage.
• When OneTake only has an acquisition date to go on, rather than the item's actual build year, that date can only tell you the item is at least that old — not its exact build year. In that case Reverb caps the search at that year and searches no window below it, rather than guessing at a build year it doesn't actually have.

Because the window is narrower than a plain cutoff, a thinly-listed vintage item is more likely to return very few comparable listings — which, as before, is treated as an honestly thin sample rather than worked around by pricing it against gear from a noticeably different era.

When a recorded vintage year doesn't hold up

Sometimes an item is recorded with a year that doesn't match any real listings from that era — for example, a modern piece of gear mistakenly entered with a much older year. When a vintage-windowed search for an item like this turns up too few usable listings, OneTake checks further before settling for a thin answer: it searches again with no year restriction at all.

If that broader search turns up enough listings with a clear, recent build year, and none of them actually look vintage, OneTake concludes the recorded year was wrong and prices the item as current production from that broader search instead.

If even one listing from that broader search does look vintage, OneTake keeps its original — thinner, but better-targeted — vintage-era answer rather than switching.

Outlier prices are trimmed

Once the sample is otherwise cleaned, OneTake drops any remaining prices that sit well outside the typical range of the rest — a stray very-low or very-high listing that slipped past the other checks — before taking the median. This only comes into play once there are at least four listings to compare; smaller samples are priced as-is.

Wide price spreads are capped at low confidence

A search for a broad family name without a specific model — for example, "Fender Telecaster" with no model given — can return everything from an entry-level guitar to a Custom Shop build costing several times as much. Averaging across a spread that wide produces a number that doesn't describe any actual guitar. The same thing can happen on a specific-looking search whose keywords still match more than one real product line — for example, eBay's "Music Man StingRay" also pulls in Sterling by Music Man basses.

When the cleaned sample's prices are too spread out — specifically, when the priciest quarter of the listings costs more than twice the cheapest quarter — OneTake caps that estimate's confidence at low, no matter how many listings it found. This check runs the same way on both Reverb and eBay. A low-confidence estimate from one provider isn't the final word: OneTake still checks the other, and uses whichever of the two is stronger. See How OneTake picks a source.

A model with a consistent going price is unaffected by this check — it only trims cases where OneTake's search unintentionally matched a wide range of distinct things with very different values. Samples with fewer than four listings are too small to measure a spread and are never capped by this rule.

When a wide spread means your model name is too vague

A wide-spread, low-confidence quote usually just gets quietly skipped in favor of the other provider's number, or falls back to depreciation like any other low-confidence result. But when the spread is wide and the sample is large — and neither provider can do any better — OneTake tells you directly, instead of silently falling back with no explanation.

This more specific message only appears once the wide-spread sample has at least 8 listings. A smaller uneven sample (4 to 7 listings) is still capped at low confidence, but is treated as an ordinary thin-sample result instead — see When an acceptance fails below — since a handful of mismatched listings could just be a thin market for a correctly-named item, not proof the name itself is too broad.

When it does apply, the market value preview shows:

"Prices vary too much to estimate. The listings we found cover several different models, so the model name is probably too general — for example "Telecaster" instead of "Player Telecaster". Add the specific model in the edit view and try again — until then we'll fall back to depreciation for this item."

This is a different message from the thin-sample "not enough listings" warning — here, OneTake found plenty of listings, they just don't agree with each other on price. If another provider manages to return a medium-or-better estimate, that estimate is used instead and this message never appears — the wide-spread quote only surfaces when nothing stronger is available.

If, on top of this, Reverb itself couldn't be reached during the same lookup, OneTake adds a line to this message too — see When neither provider has a usable number above.

When an acceptance fails

Single item

If the acceptance cannot be fully finalized, OneTake shows an error message along the lines of "The value was applied but could not be finalized. Please retry."

The estimate has not been recorded as accepted. You can retry and the operation will complete cleanly — the value update is idempotent and the acceptance guard still holds, so retrying does not duplicate anything.

Bulk accept

When you accept multiple estimates at once, each item is processed independently. If the acceptance for one item fails to finalize, that item is reported as failed in the results — it is not counted toward the accepted total.

Items that succeed are counted normally. Items where the estimate was already accepted by a concurrent operation are also counted as accepted — they are not reported as failures.

Before marking anything as accepted, OneTake also guards against promoting a market value onto an item that's since been set to Agreed value with a positive amount. If that's happened, the lookup is reported as skipped — not failed, and not accepted — with reason: 'agreed_value'. No market value is written and nothing is marked accepted, so the agreed amount stays the item's value. See Agreed-value items are skipped entirely above.

This check is applied as a condition on the same database write that applies the market value, rather than as a separate check made just before it — so an item that switches to Agreed value in the instant between the two steps still can't have a market value written over its agreed amount.

If the update matches no rows, OneTake can't yet tell whether that's because the agreed-value guard just described blocked it, or because the underlying gear record is no longer there at all — for example, it was deleted, or it's no longer visible to you. It checks once more to tell the two apart:

• If the item still exists, OneTake treats it as the agreed-value guard having blocked the write, and reports it as skipped with reason: 'agreed_value', as above.
• If the item genuinely can't be found, it's reported as failed instead, with reason: 'equipment_not_found' — so a deleted or inaccessible item doesn't get silently counted as an ordinary agreed-value skip.

A separate, earlier kind of "failure" can also show up here: when a bulk lookup runs across many items, some items may come back with no usable quote at all — for example, no listings, too few listings, or an ambiguous model — rather than failing to finalize an acceptance. Those items are reported without a quote so you can see which items need more specific gear details, rather than being silently skipped.

What does not change after a failed acceptance

• No acceptance event is recorded in the audit log for an item whose acceptance did not complete.
• The item's estimate lookup is not marked as accepted — it remains available to retry.

The same is true for an agreed-value skip: no audit event is recorded, and the lookup is left exactly as it was so a later change — removing the agreed value, or clearing its amount — leaves the estimate available to accept. The same holds for the scheduled refresh's own race-closing skips — both the agreed-value kind and the not-found kind — see How the scheduled refresh closes the same race above.