Scrape auction listings and results from RitchieBros.com (RB Auction), the world's largest industrial auctioneer. Extract hammer prices, lot details, make, model, year, hours, location, and photos. Track equipment values across construction, agriculture, and transportation.
Changelog — Ritchie Bros Scraper — Heavy Equipment Auctions
2026-10-04 — tiempo_uso con unidad (pendiente build, aprobación David)
ext_tiempo_uso_unidad (h|km|mi|null) y ext_tiempo_uso_calidad (cero|horas_igual_km|unidad_sin_confirmar|null) en _rb_to_ftp (live, preloaded crudo, snapshot sold) y, para registros ya almacenados en FTP-28 o inglés+ext (master de remates), vía _fill_uso_rb idempotente en _to_out, sin re-scrapear. Formato de tiempo_uso intacto ("N h" / "N km" / "N mi"; millas SIN convertir). Único cambio de valor: horas=0 con km/mi ya no devuelve "0 h" ocultando el km. Medición (muestras sept): active 1000 -> 591 con uso antes y después (546 h, 45 km, 0 mi); sold 2000 -> 1043 (609 h, 434 km, 0 mi); hours en esquema inglés idéntico en el 100 %. Declaradas en dataset_schema.json.
2026-09-18 — build FTP-28: R1
T7 (push 2026-09-18): _update_pointer hace merge sobre el pointer existente en vez de sobrescribirlo entero, preservando el campo "master" (historyScope=full) que un snapshot delta mensual borraba silenciosamente en cada actualizacion.
Formato: que cambio, por que, y la medicion que lo respalda. Un cambio sin numero detras es
una opinion; en este repo no cuenta como entrada de changelog.
Las versiones son las de Apify (mayor.menor). La plataforma no admite numero de parche.
[1.0] — 20 de agosto de 2026
Corregido — el modo remates emitia cero registros
El esquema de entrada declara listingStatuses: ["Open"] por defecto y Apify lo inyecta en toda
ejecucion aunque el cliente no lo escriba. Contra un snapshot que es 100% Sold, ese filtro
descartaba los 1,5 M de registros uno a uno: el run recorria el dataset entero, emitia cero y moria
por timeout. runPreset: "custom" no lo corregia, porque el valor lo pone el esquema, no el preset.
Medido con el mismo input, antes y despues:
antes 4 min 00 s ->0 registros -> timeout
despues 0,74 s ->1.000 registros
Se diagnostico durante tres dias como lentitud de lectura. Era filtrado.
Corregido — el esquema ingles del maestro no se convertia a FTP-28
run_preloaded reconocia dos formas —FTP-28 y el payload crudo de la API— pero no la tercera: el
ingles + ext_* del maestro de remates. La pasaba por _rb_to_ftp, que solo entiende claves
camelCase, y devolvia marca, modelo, anio y precio a null. Mismo patron que tuvo mobile.de.
Corregido — url salia en la posicion 31 en vez de la 5
Se llama igual en los dos esquemas, asi que caia por el bloque de campos no mapeados. Los 31 campos
FTP-28 ya salen en orden canonico exacto.
Corregido — emitir cero ya no termina en SUCCEEDED
Si el run recorre el snapshot entero sin emitir nada, Actor.fail() con el motivo. Un fallo
silencioso llega al cliente sin que nadie se entere.
Anadido — soldFrom / soldTo
Filtran por fecha de martillo (ext_gql_sold_time_iso), no por mes de raspado. El maestro
entero cuesta ~$2.876 por ejecucion; el incremento de agosto son 24.790 registros por ~$47.
Verificado: 24.790 emitidos en 6 min 18 s, todos con valor y moneda.
snapshotMonth no sirve para esto: filtra por mes de raspado, y en un maestro acumulativo los
1,5 M de registros llevan solo dos fechas de raspado repartidas sobre dos anos.
Reconstruido — el maestro de remates
Mezclaba dos esquemas incompatibles: sus primeras 52.856 filas eran el payload crudo de la API de
Ritchie (80 campos camelCase, sin item_id, sin source) concatenadas delante del cuerpo
normalizado. Y arrastraba 791.587 filas duplicadas.
antes
despues
Filas
2.252.925
1.513.925
item_id unicos
1.461.338
1.513.925
Duplicados
791.587 (35%)
0
Esquemas
2
1
Con precio de cierre
—
98,9%
Baja de 2,25 M a 1,51 M quitando duplicados, no cobertura: en anuncios unicos sube.
Rectificado — el diagnostico de "97,7% sin precio de cierre" era falso
Se midio consultando gql_soldPrice, nombre que solo usaba un bloque minoritario del maestro. El
96,9% llevaba el precio en ext_gql_sold_price. No hubo token caducado. Al comprobar la cobertura
de un campo, buscarlo por sufijo, nunca por nombre exacto.
