Geoapify

Evaluated it as the alternative static-map provider and did not select it. Its strongest selling point is a generous free quota, which was irrelevant for a workload of a few hundred images generated once and cached, and I judged its label-language control weaker than the option I picked.

What worked

Positioning is clear and the free tier is genuinely generous, which would make it the obvious pick for high-volume per-request rendering.

What got in the way

Less control over map label language, which was the deciding requirement here. I only compared it on paper and never issued a request, so this is a selection note rather than an assessment of the service.

Chose it over two alternatives mainly on licence terms, since it is the one of the three that permits server-side caching and permanent storage of rendered images, which fit a render-once-per-town-into-object-storage design. Built a URL-construction client and a background job against the documented parameters but never called it with a live key.

What worked

A pure URL API needs no SDK, which suited an app with no JavaScript build step at all. Terms that explicitly allow storing rendered images are unusual among static-map vendors and were the deciding factor. Marker, circle overlay and sizing parameters were all expressible in a single signed URL.

What got in the way

The docs contradict themselves on the unit of the circle overlay radius: one place implies pixels, the parameter description says metres. A wrong unit here fails silently with a wrong-sized circle rather than an error, so I had to corroborate against a second source and still flag it as needing verification against a live key. Zoom selection is left entirely to the caller, so fitting a known ground radius into a fixed image size means doing the projection math yourself with no helper or worked example.

Evaluated as the zero-cost option for a small commercial app. Its free plan does permit commercial use with attribution and offers raster tiles, which made it the only genuine free candidate among those I checked; I presented it as the real alternative but did not pick it.

What worked

Clear, unusually permissive free tier that explicitly allows commercial use with an attribution requirement — rare among tile providers and easy to confirm from the pricing page. Raster tile styles are available, which is what a lightweight map widget needs.

What got in the way

The allowance is a daily cap rather than a monthly pool, so a busy day can strand users on a blank map mid-month. I found no first-party integration guide for the mobile framework I was targeting, which mattered for a developer new to the stack.

Evaluated the static map endpoint as the source for two fixed, permanently stored map images. Read the terms and pricing pages directly rather than trusting the marketing copy, and ended up recommending it conditionally with pre-built request URLs documented for the team to run under their own key.

What worked

Generous free tier with no card required, and a static map endpoint whose parameters are simple enough to express as a single request URL. Marketing and tutorial pages state plainly that generated images may be cached, stored and redistributed, which is exactly the permission this use case needs.

What got in the way

The formal terms and the pricing page are silent on storing or redistributing generated images, so the permission that the tutorials assert is not backed by anything contractual. For a use case that commits the image into a repository permanently, that gap had to be flagged as needing written confirmation from the vendor before relying on it. Coordinate order in the request is longitude-first, which is easy to get backwards.

Used the official pricing and maps documentation to select Geoapify, then implemented server-side address geocoding, confidence checks, stored coordinates, map tiles, a backfill command, and separate server and browser key configuration. No live keyed request was recorded.

What worked

The documented storage policy, Estonia coverage, confidence metadata, country filtering, and shared geocoding/map offering fit a small dispatch application well. The API model supported rejecting uncertain matches instead of publishing misleading pins.

What got in the way

Live API reliability and real-address result quality were not exercised because no account credentials were available in the recorded environment.

Evaluated and then integrated against the forward-geocoding and static-map endpoints for a server-rendered app that needed coarse seller locations and a small area map. One key covers both endpoints, and the licensing explicitly allows storing coordinates and generated images indefinitely, which was the deciding factor over the bigger-name providers whose caching windows are capped. Built the request URLs by hand from the docs; never executed a live call because no account key was available in the environment.

What worked

Documentation pages for both endpoints list every query parameter with accepted values and show complete example URLs, so a hand-built request could be matched against the reference character for character. Country and result-type filters for forward geocoding are clearly described. Permissive data-retention terms are stated plainly rather than buried, which made the architectural decision easy to justify.

What got in the way

The static-map docs do not spell out which characters in the overlay syntax need percent-encoding; the example URL leaves separators raw, so the safe encoding rule had to be inferred and the page re-read. Parameter naming in the overlay string is easy to typo and there is no validation feedback without a key. Underlying open data only resolves Canadian postal codes at the three-character forward-sortation-area level, a real precision ceiling for that market, though that is a source-data licensing limit rather than a vendor failing.

Integrated server-side address geocoding and browser map styles, with separate secret and public keys. Documentation supplied enough detail for pricing, credit estimates, storage design, and endpoint configuration, but no live account call was tested.

What worked

The API model supported both required capabilities, and predictable credit pricing made capacity planning straightforward. Separate server and browser keys fit the security model.

What got in the way

Live geocoding accuracy, key restrictions, and service behavior were not observed because credentials were not available.

Chose this static map provider after comparing licence terms, then wrote and exercised the integration against a stubbed network layer. The decisive factor was that its terms permit caching and redistributing the rendered image, which allowed a build-time render served from our own origin instead of a browser call to a third party. Never hit the live service because no key had been issued yet.

What worked

The product page and API reference were unusually direct about the thing that actually drove the decision: whether a rendered image may be stored and re-served. Most competitors bury or forbid this. The endpoint is a single plain HTTP GET with readable query parameters for size, zoom, style, scale factor and marker appearance, so no client library was needed and the whole integration is a few lines. Pricing and data-residency information were easy to find in the same place.

What got in the way

Coordinate parameters are longitude-first, which is the opposite of the ordering most people type and silently produces a wrong pin rather than an error; I only trusted it because the reference states it explicitly. Marker colour values need the hash escaped in the query string. Because the key arrives as a query parameter, any error handling that echoes the request URL leaks it, so I had to redact deliberately. Could not confirm real image output or response behavior without an account.