BLM Mining Claims Search & Monitor API — Lode/Placer (MLRS) avatar

BLM Mining Claims Search & Monitor API — Lode/Placer (MLRS)

Pricing

from $4.40 / 1,000 results

Go to Apify Store
BLM Mining Claims Search & Monitor API — Lode/Placer (MLRS)

BLM Mining Claims Search & Monitor API — Lode/Placer (MLRS)

Search and monitor US federal mining claims from the official BLM MLRS national dataset. Filter by state, claim type (lode / placer / mill site) and status, and track newly recorded or modified claims. Mineral-rights and land data. Keyless, official source.

Pricing

from $4.40 / 1,000 results

Rating

0.0

(0)

Developer

Kyle Maloney

Kyle Maloney

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

0

Monthly active users

2 days ago

Last modified

Share

BLM Mining Claims Search & Monitor (MLRS)

Search and monitor US federal unpatented mining claims from the official BLM Mineral & Land Records System (MLRS) national dataset — lode claims, placer claims, mill sites and tunnel sites — with PLSS legal locations, case serials, status, acreage and change dates. Keyless, official, public-domain source.

This is a screening tool, not a title determination. The BLM spatial layers do not carry claimant or owner names; those live only in separate MLRS case reports.

What v1.1 fixes (read this if you used v1.0)

Every change is append-only — no field was removed or renamed. Five defects meant v1.0 could bill you for a confident wrong answer while the run reported SUCCESS:

  • states: ["AR"] returned zero rows while 18 Arkansas claims existed. The state filter matched only the case-serial prefix, but BLM's Eastern States office files everything east of the Mississippi under an ES serial, with the real state appearing only in the PLSS legal description. v1.0 also emitted state: "ES" — not a US state. The filter now matches the serial prefix or the PLSS state, and state resolves correctly.
  • A disposition that cannot exist returned an empty dataset on a green run. v1.0's own input schema advertised Closed and Void. Closed exists only in the Closed layer (so it matched nothing unless includeClosed was set) and Void does not exist in either layer. Both now fail the run with the valid values listed, before anything is billed.
  • A failed BLM layer was swallowed. v1.0 logged a warning and continued, so a dead Not Closed layer produced a green run holding only closed claims — or nothing. A partial answer is now a loud failure.
  • Delta mode never worked. monitor: true used Apify's default key-value store, which is created fresh for every run, so the "already seen" baseline was always empty and every run re-emitted — and re-billed — the entire result set while reporting it as "only new since last run". It now uses a named, filter-scoped store.
  • Truncation was invisible. A default Nevada query matches over 275,000 claims and returns maxResults of them with no indication. Every row now carries layer_total_matching and result_truncated.

"Not Closed" is not "Active"

Measured live 2026-08-01, the Not Closed layer holds 578,019 records:

DispositionRecordsShare
Active417,48972.2%
Filed153,34826.5%
Under Review6,0761.1%
Submitted1,0970.2%
On Appeal5
Appeal - Stay Granted2
Pending2

27.8% of "not closed" records are applications, not adjudicated active claims. Use is_active and claim_status_group rather than assuming the layer means active. The Closed layer (80,095 records) carries exactly one disposition: Closed.

Who it's for

  • Title & land professionals — screen a section or township for unpatented claims before acquisition.
  • Mineral exploration & staking — find open ground, track competitor staking activity by state and claim type.
  • Mining companies & royalty holders — monitor claims adjacent to a position.
  • Environmental & permitting consultants — surface federal mining claims in a project footprint.
  • Data teams & AI agents — clean, flat, keyless claim records with structured status and data-quality flags.

Example input

{
"states": ["NV"],
"claimType": "Lode",
"disposition": "Active",
"maxResults": 200
}

New and updated claims since a date, across two states, including closed cases:

{ "states": ["AZ", "NM"], "sinceModified": "2026-01-01", "includeClosed": true, "maxResults": 500 }

Recurring new-claim alert (named cross-run baseline, first run establishes it):

{ "states": ["NV"], "claimType": "Placer", "monitor": true, "maxResults": 1000 }

Output fields

Every field the actor declares.

FieldDescription
claim_nameName of the mining claim
claim_typeClaim/product type exactly as BLM publishes it (casing is inconsistent upstream)
claim_type_normalizedNormalized: Lode Claim, Placer Claim, Mill Site, Tunnel Site
is_national_park_claimTrue when BLM tags the claim as within a National Park unit
dispositionCase disposition exactly as BLM publishes it
claim_status_groupactive / pending / appeal / closed; null when BLM returned a disposition outside the known vocabulary
is_activeTrue only for Active. null when the disposition is unrecognised
disposition_knownWhether the disposition is in the known BLM vocabulary
case_serialBLM case serial number
legacy_serialLegacy (LR2000-era) case serial, when present
case_type_numberBLM case type number
stateTwo-letter US state code
state_from_case_serialState implied by the serial prefix, when that prefix is a state
state_from_plssState at the front of the PLSS legal description
state_sourceWhich field state came from: case_serial or plss_meta
admin_office_codeThe two-character serial prefix — a state, or a BLM office
admin_office_nameOffice name when the prefix is an office (ES = Eastern States)
plss_state_codesEvery distinct state across the claim's PLSS descriptions
acresRecorded acreage of the claim
plss_locationFirst PLSS legal land description
plss_descriptionsAll PLSS aliquot descriptions
parcel_countNumber of PLSS parcels
data_quality_scoreBLM geocoding quality score parsed from QLTY
data_quality_notesThe free-text remainder of BLM's geocoding diagnostic
data_quality_flagsTOWNSHIP_NOT_FOUND, PM_ANGLE_MISMATCH, OVERLAY, UNCLEAN_TOWNSHIP, UNNUMBERED_LOT, FIRST_DIVISION_ONLY, MAPPED_TO_WHOLE_DIVISION
data_sourceBLM source code for the record
blm_case_idBLM internal record identifier
stage_case_idBLM staging system case identifier
salesforce_idBLM MLRS Salesforce record identifier
objectidArcGIS feature object id within the layer
created / modifiedRecord create and last-modified dates (YYYY-MM-DD)
status_layerWhich BLM layer the claim came from: not_closed or closed
layer_total_matchingHow many records in that layer match your query in total
result_truncatedTrue when the layer held more matches than maxResults returned
source_statusPer-layer outcome: ok when the BLM layer answered
source_errorWhy the layer did not answer, when it did not
source_system / source_urlBLM MLRS and a link to the MLRS system

Fields that are legitimately null on a healthy run, with an input that populates them: legacy_serial, data_source, stage_case_id and salesforce_id are sparsely populated by BLM; admin_office_name and state_from_plss populate on Eastern States records (states: ["AR"]); state_from_case_serial populates on every other record; data_quality_notes / data_quality_flags populate where BLM recorded a geocoding caveat; source_error populates only when a layer fails, in which case the run fails and emits nothing.

Reliability: what makes this fail loudly instead of answering wrongly

Every run checks the live service before any billable row is written:

  • Layer resolves and still carries every field a row depends on. A retired ArcGIS service returns HTTP 200 with an embedded error, not a 404 — that is caught.
  • Truncation guard read from the service's own maxRecordCount, never a code constant, and paging is sized from it. Records repeated across page boundaries are de-duplicated and counted.
  • Row-count bands — each layer's total must sit in a measured band (Not Closed 578,019; Closed 80,095, both 2026-08-01), so a re-scoped or emptied layer fails instead of quietly returning a different dataset.
  • Disposition vocabularyActive must still return rows in Not Closed and Closed in Closed. If BLM changes the vocabulary, every status classification would be silently wrong, so the run fails.
  • Positive canary — case serial NV105216280 ("WR 195") must resolve to exactly one record, and to that record.
  • Negative control — the impossible serial ZZ000000000 must match zero records. If it ever matches rows, BLM is ignoring the where clause and every filtered answer would be a full-layer dump wearing your filter's label. The run fails immediately.
  • No silent zero — a query matching nothing fails with the counts that explain it. An impossible disposition fails before any request.
  • All-or-nothing layers — if any selected layer fails, the run fails rather than presenting a partial answer as a complete one.

Every measured value is logged on every run, so the bands can be tightened on evidence.

Use as an MCP tool

Callable by AI agents (Claude, Cursor, etc.) via mcp.apify.com. "Are there active lode claims in Nevada modified since January?" maps directly to states + claimType + disposition + sinceModified. Agents should read is_active (null means not classified, never not active) and result_truncated before treating a result set as complete.

Pricing

Pay per result: $8 per 1,000 claim records. Graduated discounts apply on paid Apify plans. A run that fails a reliability gate emits nothing and bills nothing.

FAQ

Where does the data come from? The BLM National MLRS mining-claim FeatureServers (gis.blm.gov), public domain, no API key. Not Closed and Closed are separate layers.

Does it include the claimant / owner name? No. The BLM spatial layers do not publish claimant names; they exist only in MLRS case reports. Use case_serial to look a claim up at mlrs.blm.gov.

Which states have claims? AK, AZ, CA, CO, ID, MT, NM, NV, OR, UT and WY, plus a small number administered by BLM Eastern States (currently Arkansas). Nevada alone holds 275,828 not-closed claims.

Why did my run fail with "not a BLM MLRS case disposition"? You asked for a status BLM does not use — most often Void. The message lists the valid values. This is deliberate: returning an empty dataset would read as "there are no such claims".

Did I get all the claims? Check result_truncated and layer_total_matching on any row. Rows come back most-recently-modified first, so raise maxResults or narrow the filter.

What does a data_quality_flags value mean? BLM records how confidently it mapped the claim's PLSS description. TOWNSHIP_NOT_FOUND or PM_ANGLE_MISMATCH means the mapped location is less reliable — worth verifying against the case file.

  • PAD-US Protected Lands Screener — federal land manager and protection status for a coordinate.
  • BLM Sage Grouse Siting Screener — habitat-management overlays on BLM ground.
  • Energy Corridor Section 368 Screener — designated federal energy corridors.
  • USGS Bedrock Geology & Lithology Screener — mapped bedrock units and mineral-relevant lithology.