Looking for the overview — what this API returns, what it costs, and a call you can run without a key? See the HiBid API page →
Classifieds & Second-hand

HiBid API & Scraper

The HiBid API returns North America's largest auction aggregator as clean JSON in six actions: search, detail, bids, auctions, houses and categories.

6 actionsLive JSON1,000 free credits$0.67–$1.50 / 1,000 creditsMCP-ready
Get a free keyOpen in playground

🤖 Using an AI assistant? Copy this link into ChatGPT / Claude / Cursor — it reads every endpoint and parameter instantly and tells you if this API fits your use case.

HiBid holds no stock of its own — it is one shop window over thousands of independent auction houses — so the thing that makes this API useful is on every single row: auction_house, with the house's id, trading name, street, town, state, postcode, country, phone, e-mail and its own website, next to auction, with the sale's id, name, lot count, currency, location, buyer's premium and the HiBid links to the sale and its catalogue, and the lot's own URL. Measured on 2026-10-01 across 240 rows in each of two runs, those house fields were filled on 100 % of rows except the house's own website at 82.9 %, and a single 100-lot page touched 39 different auction houses. Because an auction is live, the bidding state comes with it: current_bid, bid_count, next_bid_amount, reserve_met, the normalised state (open or closed), HiBid's own status word, and closes_at — the lot's own closing instant in UTC, derived from the seconds HiBid publishes rather than from its printed timezone label, which was measurably wrong (100 of 107 rows said EST on a date when that zone was on daylight time). search offers ten filters that were each measured to move HiBid's own total in the same run, twelve stable sort orders, 1 to 100 lots a page, and a lot_ids parameter that returns up to 100 named lots in one call. One of those filters is worth calling out: HiBid's rows spell the country United States, but its own filter answers 21 lots for that spelling and only 2 for USA, with no error either way, so this API maps USA, US and America onto the spelling the rows use rather than passing them through. detail adds every picture, the category path root-first, the sale's complete terms — buyer's premium, bid increments, payment, shipping and pickup, preview and checkout dates, terms and conditions — and optionally the public bid ladder in the same call. bids returns that ladder on its own: each amount, how many bids landed on it, and the timestamp HiBid prints. auctions searches the sales rather than the lots, and is also how you work house by house, because HiBid publishes no auction-house filter on lots. houses is the directory itself. No HiBid account, no browser — one ReefAPI key and the standard { ok, data, meta, error } envelope.

Reference

One lot, and the auction house actually selling it

A HiBid row is a lot inside somebody else's sale. Without the house, a lot id is a dead end: you cannot verify the item, ask about condition, arrange collection or check the terms. So every row carries the house and the sale beside the bidding state, and the lot's own HiBid URL resolves with or without a slug.

LotCurrent bid / next bidCloses (UTC)Auction houseSale
Rolex wallet — lot 93, 2 bids (320966322)USD 50 / next 752026-10-16T18:59:36ZClear Lake, TX — phone and e-mail on the rowSugarland Estate, YACHT, Jewelry Collection ONLINE AUCTION (774332), 143 lots, premium 15
Rolex Oyster Perpetual 16613 Submariner — closedno bid publishedclosed; sale closed 2026-10-16 localsame house block on the rowarchive sale, 6 pictures still served
Rolex 18k Gold Oyster 6917 Lady President — SOLDUSD 2,400 realisedclosedhouse block on the rowprice_realized set because the house uploaded it

Captured live on 2026-10-01. Auction lots close within days or weeks, so these ids are dated — take fresh ones from search. The second row is the honest case the archive is full of: HiBid returns priceRealized 0 with its own sentence 'Price Realized Not Uploaded', so this API returns price_realized: null, price_realized_note with that sentence and is_sold: null rather than claiming the lot sold for nothing.

Live example

Real request and response JSON

Captured from the indexed primary action, search, on .

Captured request
{
  "method": "POST",
  "url": "https://api.reefapi.com/hibid/v1/search",
  "headers": {
    "x-api-key": "$REEF_KEY",
    "content-type": "application/json"
  },
  "body": {
    "query": "rolex",
    "max_results": 10
  }
}
Captured response
{
  "ok": true,
  "meta": {
    "api": "hibid",
    "endpoint": "search",
    "mode": "live",
    "latency_ms": 804.4,
    "record_count": 10,
    "bytes": 42454,
    "cache_hit": false,
    "stop_reason": "limit_reached",
    "total_available": 572,
    "total_is_capped": false,
    "reachable_pages": 58,
    "duplicate_ids_in_page": 0,
    "distinct_auction_houses_in_page": 8,
    "currencies": {
      "USD": 10
    },
    "sort": "LOT_NUMBER",
    "charged_credits": 1,
    "version": "1.0.0",
    "request_id": "c547b7bbd17e4867",
    "queue_ms": 2.3
  },
  "data": {
    "query": "rolex",
    "status": "open",
    "archive": false,
    "sort": "lot_number",
    "filters": {
      "lot_type": "all",
      "category_id": null,
      "auction_id": null,
      "state": null,
      "country": null,
      "zip": null,
      "radius_miles": null,
      "lot_ids": null
    },
    "total_available": 572,
    "total_is_capped": false,
    "total_note": null,
    "page": 1,
    "page_count": 10,
    "last_reachable_page": 1000,
    "duplicate_ids_in_page": 0,
    "currencies": {
      "USD": 10
    },
    "auction_houses_in_page": [
      {
        "id": 148470,
        "name": "A&B Gemological Services"
      },
      {
        "id": 29322,
        "name": "Lilly's Auction & Gallery"
      },
      {
        "id": 90970,
        "name": "Garnet Gazelle"
      }
    ],
    "amounts_note": "Every amount is in that row's own `currency` as the auction house publishes it; nothing is converted.",
    "paging_note": "Rows are ordered by `sort`. hibid.com returns a random sample when no order is given, so this engine always sends one; measured repeat across three consecutive live pages was 0.33-0.67%, and 4.67% on the archive.",
    "__trimmed": "response capped for page display"
  }
}
Actions

What the HiBid API does

ActionDescriptionConcrete use caseKey params
searchSearch HiBid's whole catalogue of live and timed online auction lots across thousands of independent North-American auction houses, or its closed archive. Every row names the auction house it belongs to — name, town, state, country, phone, e-mail and its own website — plus the sale it sits in and the HiBid lot URL, so any lot can be traced back to the house that is selling it. Live bidding state comes with it: current bid, number of bids, next bid required, buy-now, reserve status and the lot's own closing instant in UTC. Every filter is optional, but pass at least one of `query`, `category_id`, `auction_id`, `lot_ids`, `state` or `zip` — with none of them you get the newest slice of the entire catalogue.Price-intelligence teams call search to search HiBid's whole catalogue of live and timed online auction lots across thousands of inde….query, status, archive, lot_type, sort, ...
detailOne lot in full: every picture, the full category path, the lot's live bidding state, and the sale's complete terms — buyer's premium, bid increments, payment, shipping and pickup, preview and checkout dates, terms and conditions — together with the auction house's own contact details and website. Add `include_bids` for the public bid ladder in the same call. A lot whose bidding has closed is a normal answer, not an error; a lot the house has hidden or deleted comes back as NOT_FOUND and is not retried.Classifieds aggregators call detail to get one lot in full.lot, include_bids
bidsThe public bid ladder of one lot: each amount, how many bids were placed at it, the timestamp HiBid prints and the bidder name HiBid itself masks. `bid_count` on the lot counts BIDS, this list counts AMOUNTS, so the two differ on purpose (measured: bid_count 16 against 3 ladder rows).Resale and arbitrage tools call bids to get the public bid ladder of one lot.lot
auctionsSearch the SALES rather than the lots: which auctions are running or coming up, how many lots each holds, when bidding opens and closes, where the sale is, what the buyer's premium is, and which auction house is running it. This is also the way to work house-by-house, because the lot search publishes no house filter: take `auction_id` from here into `search`.Lead-generation teams call auctions to search the SALES rather than the lots.query, status, lot_type, auction_sort, category_id, ...
housesHiBid's auction-house directory: id, trading name, street, town, state/province, postcode and country. Search by name fragment or by state. The ids are the ones that appear as `auction_house.id` on every lot.Price-intelligence teams call houses to get hiBid's auction-house directory.name, state, house_sort, page, max_results
categoriesHiBid's full category tree — the ids the `category_id` filter takes, with their parents, children and URL paths. Measured: 18 roots, 1,135 nodes.Classifieds aggregators call categories to get hiBid's full category tree.none
Code samples

Call search from your stack

curl -X POST https://api.reefapi.com/hibid/v1/search \
  -H "x-api-key: $REEF_KEY" \
  -H "content-type: application/json" \
  -d '{"query":"rolex","max_results":10}'
MCP one-liner
Ask your MCP-connected assistant: call reefapi.hibid.search with {"query":"rolex","max_results":10}.
Use cases

Who uses this API and why

  • Collectibles and machinery dealers watch thousands of small regional sales at once and contact the house directly, because the house's name, phone and e-mail are on the lot row.
  • Price-history and comparable-sales tools mine the closed archive for realised prices, and get told which lots have a real figure and which ones the house never uploaded.
  • Sniping and bid-monitoring tools poll current_bid, bid_count, next_bid_amount and the lot's exact UTC closing second, with soft-close extension flags included.
  • Market researchers measure what a category is worth per region using the state, postcode-radius and sale filters, with every total labelled when it is HiBid's ceiling rather than a count.
  • Auction-house and inventory aggregators pull a whole sale with one sale id, or up to 100 named lots in a single call, instead of one request per lot.
FAQ

Questions developers ask before integrating

What does an auction aggregator give me that one auction house's site does not?

Breadth plus attribution in one row. HiBid is the shop window for thousands of independent North-American auction houses, and this API keeps the link to the house intact: every lot carries auction_house with the house's id, trading name, street, town, state, postcode, country, phone, e-mail and its own website, and auction with the sale's id, name, lot count, currency, location, buyer's premium and links to the sale and its catalogue on HiBid. Measured over 240 rows in each of two runs on 2026-10-01: house id, name, street, town, state, postcode, country, phone and e-mail were present on 100 % of rows; the house's own website on 82.9 %. One filter HiBid does not offer is a house filter on lots — the field simply does not exist in its lot search — so to work house by house you take an auction_id from the auctions action into search, which was verified to bite: 82 lots total and 25 of 25 returned rows in that one sale.

Does the same lot ever come back twice?

Inside one call, no: 500 rows across five queries returned 500 distinct lot ids, and the 240 pooled rows of each acceptance run did the same — 0.00 % repeat every time, and duplicate_ids_in_page reports the count on every response. Across consecutive pages it does happen, because a live auction catalogue changes while you page. Seven measurements of three consecutive live pages of 100 gave repeat rates of 0.00 %, 0.00 %, 0.00 %, 0.33 %, 0.67 %, 0.67 % and 0.67 % — small and bounded. The closed archive is worse and genuinely unstable: nine measurements of the same shape gave 0.00 %, 0.00 %, 0.00 %, 2.33 %, 4.67 %, 4.67 %, 7.00 %, 9.00 % and 10.33 %, so we publish that as a range rather than pretending it is one number. De-duplicate by lot_id when you page. What is NOT happening is the same lot being numbered twice: rows fingerprinted on title, house, sale, lot number and current bid produced zero groups with more than one id in every run.

Why does the API refuse to give me an unsorted result?

Because an unsorted HiBid result is a random sample, not page one — and that is measured, not assumed. Two back-to-back identical requests with no sort order returned 50 lots each with zero lots in common. Every real sort order returned the same 50 of 50. So this API always applies an order, lot_number by default, and the two no-order values HiBid accepts are deliberately not in the published list. That is why paging here is coherent at all; it is also why HiBid's own web grid appears to reshuffle under you.

Do the filters actually narrow the results?

All ten were measured against the unfiltered total in the same run, on a query whose total is 24 so that HiBid's 10,000 ceiling could not hide a swallow. From 24 lots: open 23, closed 1, webcast sales 3, catalogue-listing-only 0, Texas 4, Ohio 1, United States 21, Canada 1, within 50 miles of one postcode 0, shipping offered 23, one category 0. Three inputs that HiBid's schema accepts and then ignores — a date-from, a date-to and a sort direction — are not offered at all, because an offer that does nothing is worse than no offer. An unknown category id and an unknown auction id are also ignored upstream and would return the whole catalogue, so both are checked: the category against HiBid's own tree before the call, the auction against the rows that come back. A bad enum value is rejected with the allowed list rather than passed through.

How exact are the closing times?

Exact to the second, in UTC, and derived from the number HiBid publishes rather than from the sentence it prints. Two reasons. First, the lot closes before its sale does on staggered and soft closes — one measured lot closed at 13:46 while its auction closed at 14:00 — so the sale's close is not the lot's close, and both are returned separately. Second, HiBid's own timezone label is unreliable: 100 of 107 rows said EST and 7 said PST on 2026-10-01, when both of those zones were on daylight time. So closes_at is computed from the seconds-remaining figure, and the site's own sentence ships beside it as closes_at_source for anyone who wants to see it. soft_close_seconds and bidding_extended come too, because a soft close moves the moment. On archived lots the seconds are zero, so closes_at is null there and the only published moment is the sale's own local close — stated rather than invented.

Can I get hammer prices out of the archive?

Sometimes, and the API is explicit about when. HiBid returns a realised price only if the auction house uploaded one, and when it did not it says so in its own words. Measured: on one archive page 1 lot of 100 had a realised price and the other 99 carried HiBid's sentence 'Price Realized Not Uploaded'; on another, 32 of 50 had one. Across the 240 mixed rows of an acceptance run, 7.9 % carried a realised price. So price_realized is null unless there is a real figure, price_realized_note carries HiBid's sentence, and is_sold is three-valued: true when HiBid says SOLD or publishes a result, false only when HiBid says PASSED, and null when the lot is closed and HiBid published neither. Returning false there would have mislabelled 99 % of that page. Where a figure does exist it agreed with the lot's high bid.

How do I check a bid is real?

Ask the bid ladder, which is a separate HiBid surface. The bids action returns each distinct amount, how many bids landed on it, the bidder name HiBid itself masks, and the timestamp HiBid prints. We compared the top of that ladder against the lot's current_bid on eight lots and it matched on all eight, with the same currency on all eight. Note that the two counts measure different things on purpose: a lot's bid_count counts bids, the ladder counts amounts — one measured lot had bid_count 16 and three ladder rows — and the response says so.

How complete are the fields?

Counted over 240 rows in each of two acceptance runs, not assumed, and the two runs agreed to within one row. 100 %: lot id, lot url, title, lot number, quantity, currency, bid count, reserve flag, state, HiBid's status word, closed flag, seconds remaining, picture count, lead image, shipping flag, the sale's id, urls, name, lot count, currency, close time and location, and the house's id, name, street, town, state, postcode, country, phone and e-mail. Lower, and worth planning around: the sale's buyer's premium 96.2 %; HiBid's own closing sentence 89.6 %; the lot description 89.6 %, blank on about one lot in ten; the computed closing instant 83.8 %, because archived lots publish no seconds remaining; the house's own website 82.9 %; the next bid required 79.6 %, absent on closed lots; the current bid 65.8 %, because a lot nobody has bid on returns null rather than 0; and the estimate just 23.3 % — it is free text the house types, so do not build a valuation on it. Three fields HiBid returns are deliberately not passed on: rv, which matches nothing it documents; a buy-now price, which was 0 on 1,005 measured rows while HiBid's own flag claimed the feature was set; and a maximum-bid figure that only means anything to a signed-in bidder. A handle that never works is worse than no handle.

How deep can I page, and how many results are there really?

100 lots a page is HiBid's own ceiling — asking for 200 or 300 returns 100 — and the reachable window is 10,000 lots per query on the live catalogue and 1,000 on the archive. Page 400 of 25 answered; page 1000 returned nothing. The total HiBid reports saturates at those same numbers, so this API returns total_is_capped and a note saying the figure is a ceiling rather than a count: a query for 'watch' reports 10,000 and so does a filter for Canada. Narrow with a category, a sale, a state or a postcode to reach deeper lots, and a page past the window is refused with the last reachable page in the message rather than returning an empty success.

How fast is it?

The live catalogue is quick and the closed archive is not, and both are measured. Across two acceptance runs of fourteen live calls each, the median call took 982 ms and 1,065 ms and the slowest took 2,484 ms. By action: 25 lots in about 1.0-1.1 s, 100 lots in 1.8 s, one lot in full with its bid ladder in 1.4-2.3 s, the sales search in 0.8-1.1 s, the house directory in 0.7-1.0 s, and the category tree in 14 ms once it is cached for six hours. The archive is the slow surface — isolated pages measured 3.0 s to 11.3 s — so if you are mining closed lots, expect seconds, not milliseconds. The engine sizes its work to the request budget and, if it ever has to drop the optional bid ladder inside a single-lot call, says so in meta rather than returning quietly without it.

What does HiBid not publish here?

Five things it would be reasonable to want and that genuinely are not on this surface. There is no auction-house filter on the lot search — the field does not exist, which is why you go via a sale id. There is no bid-range filter and no working date-window filter. There is no buyer's premium in money, only the house's own text and rate, so a total-if-won cannot be computed from this data alone. There is no buy-now price: HiBid's buy-now figure was 0 on 1,005 measured rows even though its own flag said the feature was set, so that key is not published at all rather than always null. There is no bidder identity: HiBid masks the usernames it prints and this API does not unmask them. And HiBid's lot pages carry no structured-data copy of the price, so values here are checked against HiBid's own separate bid-history surface rather than against a second copy on the page.

Is a closed or deleted lot an error?

A closed lot is a normal, successful answer with its full record — closed is information, and three archive lots that ended months ago still returned six pictures each. A lot the auction house has hidden, or that does not exist, is a NOT_FOUND that is marked non-retryable, because no number of retries turns it into a lot. One specific case is worth knowing: if you pass the auction house's own item number instead of the HiBid lot id, HiBid answers 'hidden' — so the API says exactly that and tells you to pass the HiBid id, instead of looking like an outage.

What is the HiBid API?

HiBid API is a ReefAPI endpoint group for thousands of us and canadian auction houses as one json feed — every lot named with the house selling it, its live bid and its exact closing second. It returns live JSON through POST requests under /hibid/v1.

Is the HiBid API free to try?

Yes. ReefAPI starts with 1,000 free credits, no card required. HiBid calls use the same shared credit balance as every other ReefAPI engine.

docs / hibid

HiBid

Thousands of US and Canadian auction houses as one JSON feed — every lot named with the house selling it, its live bid and its exact closing second.

base /hibid/v16 endpoints
post/hibid/v1/detail1 credit

One lot in full: every picture, the full category path, the lot's live bidding state, and the sale's complete terms — buyer's premium, bid increments, payment, shipping and pickup, preview and checkout dates, terms and conditions — together with the auction house's own contact details and website. Add `include_bids` for the public bid ladder in the same call. A lot whose bidding has closed is a normal answer, not an error; a lot the house has hidden or deleted comes back as NOT_FOUND and is not retried.

ParameterAllowed / rangeDescription
lotrequired—The numeric HiBid lot id, or any hibid.com lot URL such as https://hibid.com/lot/320966322. The auction house's own item number is NOT accepted — HiBid answers 'hidden' for it.
include_bids = trueoptional—Also fetch the lot's public bid ladder (one extra upstream call, skipped automatically when the call budget is nearly spent and then counted in meta).
Try in playground →
post/hibid/v1/bids1 credit

The public bid ladder of one lot: each amount, how many bids were placed at it, the timestamp HiBid prints and the bidder name HiBid itself masks. `bid_count` on the lot counts BIDS, this list counts AMOUNTS, so the two differ on purpose (measured: bid_count 16 against 3 ladder rows).

ParameterAllowed / rangeDescription
lotrequired—The numeric HiBid lot id or a hibid.com lot URL.
Try in playground →
post/hibid/v1/auctions1 credit

Search the SALES rather than the lots: which auctions are running or coming up, how many lots each holds, when bidding opens and closes, where the sale is, what the buyer's premium is, and which auction house is running it. This is also the way to work house-by-house, because the lot search publishes no house filter: take `auction_id` from here into `search`.

ParameterAllowed / rangeDescription
queryoptional—Free-text search over the lot title and description (e.g. 'rolex', 'john deere 4020', 'morgan silver dollar'). Optional: leave it out and narrow with category_id, auction_id or state instead.
status = openoptionalall · open · closing · closed · hot · featured · topWhich lots to return. 'open' = still taking bids, 'closed' = bidding over, 'all' = both. 'hot', 'top' and 'featured' are HiBid's own selections.
lot_type = alloptionalall · biddable · online · webcast · absentee · listingSale format. 'online' = timed online-only, 'webcast' = live webcast/simulcast, 'listing' = catalogue listing with no HiBid bidding.
auction_sort = defaultoptionalnearest · defaultSale order. 'nearest' needs `zip`.
category_idoptional1–Restrict to one HiBid category id. Call the `categories` action for the tree (18 roots, 1,135 nodes measured). An id HiBid does not know is rejected here, because the site silently ignores it and answers with the whole catalogue.
stateoptional—US state / Canadian province, TWO-LETTER CODE ONLY (TX, OH, BC). HiBid answers zero rows for a spelled-out name, so a name is rejected here with the reason.
countryoptionalUnited States · CanadaCountry of the auction house. Pass it as HiBid's rows spell it. 'USA', 'US' and 'America' are accepted and mapped onto 'United States', because sending 'USA' straight through loses about 90% of the rows without any error (measured: 'United States' 21 lots, 'USA' 2, on a 24-lot query).
zipoptional—US/Canadian postcode to search around. Pair it with `radius_miles`.
radius_miles = 50optional1–500Miles around `zip`. Ignored unless `zip` is set.
shipping_offered = falseoptional—Only lots whose auction house offers shipping.
page = 1optional1–100001-based page. HiBid serves at most 10,000 lots per query (1,000 on the archive), so the last reachable page is that cap divided by max_results.
max_results = 25optional1–100Rows per page, 1-100. HiBid's own ceiling is 100: asking for 200 returns 100.
Try in playground →
post/hibid/v1/houses1 credit

HiBid's auction-house directory: id, trading name, street, town, state/province, postcode and country. Search by name fragment or by state. The ids are the ones that appear as `auction_house.id` on every lot.

ParameterAllowed / rangeDescription
nameoptional—Name fragment, e.g. 'estate'. Matched as a wildcard.
stateoptional—US state / Canadian province, TWO-LETTER CODE ONLY (TX, OH, BC). HiBid answers zero rows for a spelled-out name, so a name is rejected here with the reason.
house_sort = nameoptionalname · locationDirectory order.
page = 1optional1–100001-based page. HiBid serves at most 10,000 lots per query (1,000 on the archive), so the last reachable page is that cap divided by max_results.
max_results = 25optional1–100Rows per page, 1-100. HiBid's own ceiling is 100: asking for 200 returns 100.
Try in playground →
post/hibid/v1/categories1 credit

HiBid's full category tree — the ids the `category_id` filter takes, with their parents, children and URL paths. Measured: 18 roots, 1,135 nodes.

Try in playground →
Built for volume
5M+ requests a day

Measured at 60 requests a second across the fleet, with no central bottleneck. Volume pricing is on request, and per-key limits are raised for high-volume accounts.

Missing a source?
We build it

Tell us a site we do not cover yet and it becomes an engine. A customer asked for bestprice.gr on a Sunday and it was in the catalog the next day.

Support
2 minute median reply

Median time from a question in the live chat to the first answer, measured across every answered conversation. Setup help included, no support tier to buy.

One key, one balance
Every API included

No per-site plans and no separate subscriptions. One key and one credit pool across the whole catalog, so adding a source costs nothing up front.

Planning something large? Tell us the volume and the sources and we will come back with what it costs and what we would have to build.