Scrape active equipment listings from Ritchie Bros (RB Auction), IronPlanet and GovPlanet. Extract make, model, year, hours, location, photos and inspection data across construction, agriculture and trucks. No login. Export to JSON, CSV or Excel.
Changelog — Ritchie Bros Scraper — Heavy Equipment Auctions
2026-10-21 — retirada de historyScope del input
Eliminado el campo historyScope del input schema (el histórico completo vive en rastriq/machinery-sold-prices). Se elimina el campo entero y no solo el valor full para no romper schedules/tasks con inputs guardados: el schema no restringe propiedades extra y el código sigue aceptando historyScope=full, sirve el último mes y avisa en log. README sin referencias al parámetro. Dataset rbauction-sold-master intacto (archivo frío).
2026-10-20 (b) — aviso de migración del histórico (pendiente deploy tras publicar el actor nuevo)
2026-10-20 — preloaded_sold fijado al último mes (pendiente build, aprobación David)
historyScope=full deja de servir rbauction-sold-master (1.670.753 ítems): se sirve el delta del pointer (rbauction-sold-2026-10, 93.574) y se avisa en log. El master se leía con AUTHOR_DATA_TOKEN y cada run filtrado lo recorría entero a cargo del autor: 20-oct, 143.564.988 DATASET_READS (51,68 $) + 25,6 GB transferencia externa (4,87 $) ≈ 86 escaneos completos. Coste por run filtrado: ~0,66 $ → ~0,04 $.
Fail-closed: si el pointer rbauction-sold apunta al master, el run falla sin leer.
run_admin_snapshot_sold ya no reescribe pointer.name con el master (lo dejaba servido incluso en latest); solo actualiza el metadato master.
Freno operativo aplicado antes del build: eliminado master del pointer (backup en scratchpad de la sesión).
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.
