CA CalGEM Oil & Gas & Geothermal Well Register avatar

CA CalGEM Oil & Gas & Geothermal Well Register

Pricing

$1.00 / 1,000 california oil/gas well registration records

Go to Apify Store
CA CalGEM Oil & Gas & Geothermal Well Register

CA CalGEM Oil & Gas & Geothermal Well Register

California oil & gas / geothermal well register (public CalGEM data, ~242k wells): status (active/idle/plugged), well type, operator, county, field, HPZ, location. Due-diligence for environmental & mineral-rights research. Filter by county, operator, status, API number.

Pricing

$1.00 / 1,000 california oil/gas well registration records

Rating

0.0

(0)

Developer

Wenhao Yang

Wenhao Yang

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

2 days ago

Last modified

Categories

Share

CA CalGEM Oil & Gas & Geothermal Wells - California Well Register

California's Dept of Conservation / CalGEM publishes its well register (WellSTAR) as a free public map service - every oil, gas and geothermal well ever filed with the state. This actor turns it into a queryable, charged-per-record API - for environmental due-diligence, mineral-rights and land research, and oil & gas supply-chain vetting.

What it covers

~242.5k wells across California (layer 0 of CalGEM's WellSTAR service). Each record carries:

FieldWhat it is
apiNumberthe 10-digit API number - the stable per-well key
statusActive (53.9k) / Idle (30.3k) / Plugged (146.6k, sealed) / Canceled / New / PluggedOnly / Unknown
wellTypeOil & Gas / Waterflood / Cyclic Steam / Steamflood / Observation / Gas Storage / Water Disposal / Dry Gas ...
operatorNamewho operates the well (Chevron, Aera Energy, California Resources...)
county / districtlocation (Kern is the giant; offshore areas are suffixed 'Offshore')
fieldName / areaNameproducing field
leaseName / wellNumberlease and well-on-lease identity
section / township / range / baseMeridianPLSS survey location
spudDate / spudYearwhen the well was first drilled
inHPZverified high-pressure-zone wells
isConfidential / isDirectionallyDrilledflags
latitude / longitudecoordinates

Typical questions

  • "How many active wells does this operator run in Kern County?"
  • "Which wells are in a verified HPZ near this township/range?"
  • "Every plugged well on this lease - did the site get sealed?"
  • "Where are California's gas-storage wells (for storage-safety diligence)?"
  • "New wells spudded since 2020 by county."

Honest limits

The register is a status snapshot, not a production ledger: it carries no depth, plug-report or bond columns, and no per-well "last updated" timestamp (CalGEM exposes those only through other systems). Spud date is a text column, so year filtering happens after a bounded scan. Don't build depth-history claims on this data.

Inputs

InputWhat it does
statusActive (default when no other filter is set) / Idle / Plugged / Canceled / PluggedOnly / New / Unknown. Leave empty to search all statuses (use with a county/operator/well-type filter for a full-status view)
county / operator / leaseName / wellNumbername substrings
wellTypecode or label (OG / 'Oil & Gas', WF / 'Waterflood', ...)
apiNumberexact 10-digit API - single well
inHPZ / confidential / directionalyes/no flags
spudYearFrom / spudYearTofirst-drilled year range
latMin/latMax/lonMin/lonMaxbounding box
aggregate / groupByone row per group (county / status / wellType / operator / field / district) with a count
maxResultscap records (default 200)

Default run = up to 200 active wells - fast enough for the daily auto-test, and a live slice of California's operating wells.

Low cost

From $0.001 per record - billed only for the rows you use, with a per-run charge cap so a broad query can't surprise-bill.

The register is 242,545 wells across California's oil, gas and geothermal fields. The source publishes its drill dates as strings, not dates - so a naive year filter would silently mis-sort records - and its aggregate endpoint ignores its own row-count limit. We sidestep both: year filtering runs as a bounded scan on our side, aggregates are recomputed correctly client-side, and the source's quirky status values (a whitespace-less NotCalGEMJurisdiction, for one) are matched exactly rather than by sloppy substring. You query a clean well register by county / operator / status / API number; the data quirks stay on our side.

Source