Migrating a Zapier or Make automation to a new geocoding host
No-code automations built on a geocoding step need a different migration approach than custom code does. Here is how to handle that switch.
Self-hosting Open-Elevation vs using a managed endpoint
Open-Elevation's simplicity as an open source project cuts both ways. The request and response format is genuinely easy to work with, an array of coordinates in, an array of elevation values in meters out, but running it yourself means sourcing an elevation dataset, loading it onto a server with enough disk space to hold it, and keeping that server available whenever your application needs an answer.
Elevation datasets are not small. Depending on the resolution and geographic coverage a project needs, self-hosted elevation data can require meaningful storage, and higher resolution data for a specific region trades off against broader but coarser global coverage. That decision, along with the server provisioning and update cadence, is a real ongoing responsibility that a team takes on the day they choose to self-host rather than a one-time setup cost.
A managed endpoint removes that responsibility in exchange for depending on someone else's infrastructure and dataset choices. My Geocode's elevation lookup is a fully working endpoint returning ground elevation in meters for a given coordinate, drawn from our own elevation data rather than something you source and load yourself. Documentation is at /docs/elevation-lookup/.
The honest way to compare these two paths is to look at your actual usage pattern rather than a general preference for one approach:
- If elevation lookups are infrequent, say, generated only when a user views a specific route or location, a managed endpoint's free daily allowance likely covers the load without any infrastructure to maintain at all
- If elevation lookups happen at high, steady volume as part of a core product feature, it is worth calculating actual cost per request under a managed endpoint's pricing against the amortized cost of server and storage for a self-hosted instance
- If your use case needs elevation data at a resolution or for a region that a self-hosted dataset choice specifically optimizes for, that is a legitimate reason to keep self-hosting regardless of cost comparison
For teams moving from a self-hosted Open-Elevation instance to the managed endpoint, the request pattern (coordinates in, elevation values out) stays conceptually the same, though authentication changes to a key sent as X-API-Key, Authorization: Bearer, HTTP Basic auth, or a query parameter. There are 2,500 free requests a day with no key at all, and 2,500 more free per key per day counted per network, with prepaid credit at €0.0001 per request beyond that or an Unlimited key at €50 a month, priced the same as every other endpoint on the platform.
Neither path is universally correct. A side project that occasionally needs elevation for a handful of coordinates a day is well served by a managed endpoint's free tier alone. A team with very specific data resolution requirements for a narrow geographic area may find self-hosting is still the better fit, and that is a legitimate outcome of running this comparison honestly.