Thousands of auction houses, one feed — and every lot still names its house

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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