APIs/Elevation

Elevation API

GET /elevation?lat={lat}&lon={lon}

Get the elevation at any latitude/longitude, from the nearest grid sample, in feet and meters. Over the ocean it still returns, as a negative number below sea level. Pole to pole, no band cutoff. For forms, maps, and enriching place data.

Also ships on /point and /postal when you already have a place. Same meters, feet, and resolution field.

30m
grid resolution: pole to pole
coverage, ocean included: 2
units (meters + feet)

Try it

$ curl "https://api.parseapi.com/elevation?lat=27.9881&lon=86.925" \
  -H "X-API-Key: YOUR_API_KEY"

// 200 · ~15ms · USA
{
  "latitude": 27.9881,
  "longitude": 86.925,
  "elevation": 8729,
  "elevation_ft": 28638,
  "resolution": 30
}

Response fields

latitude: Input latitude
longitude: Input longitude
elevation: Elevation in meters (null if unavailable)
elevation_ft: Elevation in feet (null if unavailable)
resolution: Approx grid spacing in meters

SPEED

Fast from everywhere.

Median time for a /elevation response to reach a real city, first byte back, measured live from 16 cities. Not a lab benchmark. The whole trip.

15ms

20ms

APAC

44ms

LatAm

20ms

124ms

See live status →

SRTM1

The Shuttle Radar Topography Mission flew on Endeavour in February 2000 and mapped most of Earth's land with radar. SRTM1 is the 1-arc-second release, about 30 meters between samples.

That grid is what /elevation reads. The resolution field in every response is that spacing. Same open DEM GIS people have used for years, returned as meters and feet for any lat/lon.

Coverage runs pole to pole, ocean floor included, not the 60N/56S band most SRTM mirrors ship. The summit of Everest comes back as 8,729 meters, short of the surveyed 8,849 meters. Same radar-over-snow quirk in every SRTM release.

Create a free key Docs