Consolidating location APIs onto one platform: the honest case

Most engineering teams did not choose their location stack — they accreted it. A geocoder landed in Q2 two years ago because a product manager needed batch address validation. A routing call got added in Q4 because operations wanted an ETA on the dispatch screen. A static-map endpoint appeared in the PDF-report template six months later. An IP-geolocation library ended up in the middleware because analytics wanted country-level attribution without a login screen.

The result is not a location platform. It is four or five contracts, four or five API keys scattered across three teams' .env files, four or five vendor dashboards with different billing cycles, and four or five error surfaces that your on-call rotation does not fully understand. When one of them goes down at 03:00 on a Sunday, the person paged has never looked at that vendor's status page before.

This post makes the case for auditing that sprawl and consolidating onto a single platform — one key, one bill, one support thread. It also makes the honest counter-argument: single-vendor concentration has real risks, and you should go in clear-eyed. By the end you will have a concrete audit method, a code pattern for each surface, and a framework for deciding whether consolidation is worth it for your organisation.

The cost of sprawl that nobody tracks

Location-API sprawl hides costs that do not show up in any single line item on the budget. They surface in engineering time, in incident response, and in the slow drag of vendor-management overhead.

Integration surface. Every additional vendor means a separate HTTP client wrapper, a separate retry policy, a separate set of response-shape assumptions baked into your data models, and a separate mock for your test suite. Four vendors means four of everything. When you onboard a new engineer, they need to understand four different failure modes. When you deprecate an endpoint, you need to check four vendor changelogs to see whether the deprecation is upstream-driven. None of this shows up in the API invoice — it shows up in sprint velocity.

Key management and secret rotation. A geocoding key that lives in your production .env, your staging .env, your CI environment, and three engineers' local dotfiles is a key that will be in a leaked commit within two years. Multiply that by four vendors. The compliance argument for consolidation is not that one vendor is more secure — it is that four keys times four rotation schedules times four onboarding checklists equals a surface area that is four times harder to audit clean.

Billing visibility. Five separate billing cycles with different tier structures means five separate conversations with finance when a product feature spikes call volume. Consolidated billing — one invoice line, one credit pool — is dramatically easier to forecast and easier to defend in a budget review.

Vendor review overhead. Enterprise procurement teams often require security questionnaires, data-processing addenda, and annual review cycles for every external API vendor. A location stack with five vendors means five questionnaire cycles per year, five renewal negotiations, five "are we actually using this?" conversations. Teams that have gone through SOC 2 or ISO 27001 certification know that vendor count is a direct cost driver in the audit.

On-call fragmentation. The deepest cost. When your dispatch screen shows wrong ETAs at 03:00, you need someone who knows whether the bug is in the routing call, the geocoder result feeding it, or the static-map tile that renders the result. If those are three different vendors, your on-call engineer needs three browser tabs open to three status pages they have never looked at before. Consolidation does not make outages disappear — it makes the on-call investigation shorter.

Auditing your location API sprawl

Before you consolidate, you need to know what you actually have. This takes an afternoon, not a sprint.

Step 1: enumerate every location call in the codebase

Run a grep across your application code for HTTP calls to external hosts that handle location work. The patterns to look for: any call that takes lat, lng, address, postcode, ip as a parameter and returns something geographic. Check the middleware layer separately — IP-to-country lookups often live in a WAF or a request logger, not in the application code, and are easy to miss.

Build a table:

| Call site | What it does | Vendor | Credits/month (est.) | Owner | |---|---|---|---|---| | services/geocoder.py:42 | Forward geocode on checkout | Vendor A | ~8,000 | Payments team | | workers/report_gen.rb:118 | Static map in PDF | Vendor B | ~1,200 | Reports team | | middleware/geoip.js:7 | IP → country for analytics | Vendor C | ~50,000 | Analytics team | | api/routing.go:234 | ETA for dispatch | Vendor D | ~30,000 | Ops team |

Most teams doing this exercise for the first time find three to six distinct location vendors. Some find eight. The shock is not the number of calls — it is the number of teams that have quietly acquired their own vendor relationships without the platform team's knowledge.

Step 2: score each call by replaceability

For each call site, ask whether the surface it uses exists in your target platform's endpoint catalog. The honest answer to "could we replace this?" is one of three things: yes immediately, yes with some adaptation, or no — this vendor does something the target platform does not do.

The third category is where you should slow down. If one of your routing vendors provides a turn-penalty matrix that your dispatch algorithm depends on, and the target platform does not expose that parameter, consolidation of that call site is not a simplification — it is a feature regression. Put it in the "keep separate" column and move on.

Step 3: calculate the total annual vendor overhead

Sum the contract costs, then add an honest estimate of engineering-time cost: hours per year spent on onboarding, key rotation, incident debugging, and changelogs for each vendor, multiplied by your blended engineering cost rate. For most teams the engineering-time cost exceeds the contract cost by a factor of two to three. This is the number that makes the consolidation case to an engineering director who is already worried about introducing single-vendor dependency.

Step 4: identify your consolidation candidate

The question is not "which vendor is cheapest" — it is "which vendor covers the most of my call inventory with the least adaptation?" A platform with 56 endpoints across geocoding, routing, elevation, static maps, aerial imagery, places, boundaries, divisions, and IP geolocation covers a wide surface. But coverage is necessary, not sufficient. You also want honest answers on the calls it does not handle — a vendor who acknowledges gaps is more trustworthy than one who promises everything.

Step 5: run a two-week parallel deployment

Before you cut over, run both the incumbent vendor and the candidate in parallel on a representative traffic slice. Compare results on the dimensions that matter for your specific use cases: geocoding confidence scores, routing distance consistency, places result counts. Log both responses to the same observability pipeline — see Observability for Geocoding Pipelines for the metric shapes that matter. Two weeks of parallel traffic will surface any systematic gaps that a synthetic benchmark misses.

What 56 endpoints actually covers

Rather than describe the catalog abstractly, here is a concrete mapping from common location use cases to the endpoint group that handles them.

Address resolution — forward and reverse geocoding. The core surface: turn a human-readable address into coordinates, or turn coordinates into a human-readable address. These are the highest-volume calls for most application teams and the easiest to consolidate — the REST shape is standard, the response is predictable, and the 504M+ address dataset covers 63 countries. The batch web tool (credits = rows) covers offline enrichment jobs where you do not want to write an API loop.

Place search. Find businesses, amenities, and points of interest near a coordinate. Useful for "show nearby pharmacies" in a patient-facing app, "show petrol stations along route" in a logistics console, or "find competitors within 5 km" in a market-analysis tool.

Routing. Five transport modes (driving, cycling, walking, transit, and heavy vehicle), six endpoint variants: point-to-point route, isoline (reachability zones), distance/time matrix, map matching (snap GPS traces to road network), optimised multi-stop ordering, and locate (snap a point to the nearest road segment). The matrix endpoint is the one that tends to surprise teams — it replaces the manual loop most teams write when they need O×D travel times for dispatch optimisation.

Elevation. Global coverage at 30 m horizontal resolution. Up to 500 points per call. Anchors: Mt Everest at 8,731 m, Dead Sea shore at −415 m, Death Valley's Badwater Basin at −80 m, Mauna Kea at 4,198 m, Denver at 1,597 m, Miami at 1 m, Paris at 46 m, Tokyo at 40 m. The negative returns are the correctness signal — a provider that returns 0 for sub-sea-level points is clamping.

Static maps. A rendered map image from a coordinate, zoom level, and size. The use case is always the same: somewhere in your application generates a PDF or an email and needs a map tile that does not require a JavaScript map library to render. Report generation, printed work orders, e-mail confirmations with "here is where your appointment is."

Aerial imagery. Top-down aerial photograph per coordinate. US-only (contiguous US plus Alaska, Hawaii, and Puerto Rico). 30-day server-side cache — a repeat lookup within 30 days costs one credit, not two. Useful for property inspection workflows, insurance underwriting, and asset verification where you need a human-readable image of a physical location.

Boundaries and divisions. Administrative boundary lookups: which county, state, postcode area, or custom region does this coordinate fall in? The use case is tax-rate assignment, market segmentation, sales-territory attribution, and any workflow where the business logic depends on which administrative region a point belongs to.

IP geolocation. Country, region, city, and ISP from an IP address. The standard use case is content localisation and analytics attribution where you cannot or should not request a GPS location. Covered by the same API key pool as everything else — no separate contract for the analytics team.

REST patterns for each surface

A brief demonstration that the surface is as standard as it claims to be. All examples use the same key, the same base URL, the same response structure.

Forward geocode:

curl -G "https://csv2geo.com/api/v1/geocode" \
  --data-urlencode "q=221B Baker Street, London" \
  --data-urlencode "api_key=$CSV2GEO_KEY"

Reverse geocode:

curl -G "https://csv2geo.com/api/v1/reverse" \
  --data-urlencode "lat=51.5074" \
  --data-urlencode "lng=-0.1278" \
  --data-urlencode "api_key=$CSV2GEO_KEY"

Place search:

curl -G "https://csv2geo.com/api/v1/places/nearby" \
  --data-urlencode "lat=51.5074" \
  --data-urlencode "lng=-0.1278" \
  --data-urlencode "radius=500" \
  --data-urlencode "categories=pharmacy" \
  --data-urlencode "api_key=$CSV2GEO_KEY"

Routing (point to point):

curl -G "https://csv2geo.com/api/v1/route" \
  --data-urlencode "origin=51.5074,-0.1278" \
  --data-urlencode "destination=51.5033,-0.1196" \
  --data-urlencode "mode=driving" \
  --data-urlencode "api_key=$CSV2GEO_KEY"

Elevation (batch):

import os, requests

pts = "51.5074,-0.1278|48.8566,2.3522|35.6762,139.6503"
r = requests.get(
    "https://csv2geo.com/api/v1/elevation",
    params={"points": pts, "api_key": os.environ["CSV2GEO_KEY"]},
    timeout=15,
)
r.raise_for_status()
for point in r.json()["results"]:
    print(point["lat"], point["lng"], point["elevation_m"])

Static map:

const key = process.env.CSV2GEO_KEY;
const lat = 51.5074, lng = -0.1278, zoom = 14;
const url = `https://csv2geo.com/api/v1/staticmap?center=${lat},${lng}&zoom=${zoom}&size=600x400&api_key=${key}`;
const r = await fetch(url);
// r.body is the raw image binary — pipe to S3, attach to email, etc.

IP geolocation:

curl -G "https://csv2geo.com/api/v1/ipgeo" \
  --data-urlencode "ip=8.8.8.8" \
  --data-urlencode "api_key=$CSV2GEO_KEY"

Boundary lookup:

curl -G "https://csv2geo.com/api/v1/boundaries" \
  --data-urlencode "lat=39.7392" \
  --data-urlencode "lng=-104.9903" \
  --data-urlencode "api_key=$CSV2GEO_KEY"

Every call uses the same key. Every response is JSON (except the static-map and aerial-image binary endpoints, which return image content-types). There is no SDK to pin a version to — a thin wrapper in your language of choice around requests or fetch is all you need. SDKs exist and are documented; for enterprise pipelines, most teams prefer to own the HTTP client layer directly so they control the retry and timeout behaviour.

The honest trade-offs

Consolidation is not obviously the right answer. Write these objections down before you bring the proposal to your engineering director, because they will raise them.

Single-vendor dependency is a real risk. If the consolidated platform has an outage, your entire location stack is down simultaneously — not one surface, all of them. With a fragmented stack, a routing-vendor outage affects routing but leaves geocoding up. The answer to this objection is not to deny it — it is to ask what your current fragmented stack's real availability story is. Four vendors each at 99.5% uptime, with independent failure modes that all affect user-facing features, gives you more incidents to manage, not fewer. A single vendor's operational health is easier to monitor, easier to understand, and easier to escalate on.

Migration has a cost. Cutting over four call sites is four code changes, four test suite updates, four QA cycles, and a production deployment with a rollback plan. The one-week pilot playbook covered in One-Week Geocoding Pilot Playbook applies here — treat each surface as its own migration, run parallel deployment for two weeks, and cut over only when the comparison metrics are acceptable. Do not try to migrate all surfaces in a single sprint.

Not every surface will be a drop-in. If your routing logic depends on a vendor-specific parameter that the target platform does not expose, that call site stays where it is. Partial consolidation — migrating three of five surfaces — is still a meaningful improvement in overhead. Do not let perfect be the enemy of good.

Pricing transparency matters before you commit. The pricing page at csv2geo.com/pricing/api publishes the brackets without a quote process. The free tier gives you 3,000 calls per day to run a real parallel deployment before spending anything. Paid tiers start at $54/month for 100,000 calls. Do the maths on your actual call volume before and after consolidation, including the batching efficiency gains that come from knowing one platform's batch limits well.

What consolidation does not fix

Honest scope, because credibility matters more than a clean narrative.

Consolidation does not fix a badly designed location pipeline. If your geocoding results are being called synchronously in a user-facing render path with no cache, consolidating vendors will not fix the latency problem. Address the pipeline design first — Concurrency Tuning for Geocoding Pipelines and Caching Geocoding Results are the right prior reading.

Consolidation does not eliminate the need for observability. One vendor is easier to observe than five, but you still need per-endpoint error-rate dashboards, per-surface latency histograms, and credit-consumption graphs. The patterns in Observability for Geocoding Pipelines apply regardless of vendor count.

Consolidation does not help with surfaces the platform genuinely does not cover. Aerial imagery outside the US, change detection between two image capture dates, centimetre-scale resolution requirements, and surfaces that require vendor-specific parameters your routing logic depends on — these stay separate. Be honest about the inventory.

A note on the August series as a whole

This post is the capstone of a month of writing that has covered the hidden costs of running your own geocoder, the mechanics of migrating between providers without downtime, and how to run a one-week pilot before committing. The argument across all of them is the same: location infrastructure is a commodity layer, and engineering time spent managing it is engineering time not spent on the product problem you actually have.

The best location stack is one your team does not think about. That is the case for consolidation, stated plainly.

Frequently Asked Questions

What is the minimum commitment to evaluate the platform properly? The free tier gives you 3,000 calls per day with no credit card required. At 500 points per batch elevation call, that is 1.5 million elevation lookups per day — enough to run a meaningful parallel deployment against your production traffic slice for two weeks. Paid tiers start at $54/month for 100,000 calls. There is no minimum-term contract on the published brackets; see csv2geo.com/pricing/api for the current numbers.

How does credit consumption work when using multiple surfaces? Each API call consumes one credit regardless of which surface it uses. The batch web tool (for forward geocoding) consumes one credit per row. A routing call is one credit; an elevation batch of 500 points is one credit per point in the batch. The key insight for consolidation planning is that a single API key shares one credit pool across all surfaces — you are not managing five separate rate limits.

What happens to my existing calls during migration? Nothing — run both vendors in parallel. The migration pattern is: wire up the new endpoint alongside the old one, compare results for two weeks on real traffic, then cut over. The Migrating Geocoding Providers Without Downtime post covers the dual-write pattern in detail.

Is the 56-endpoint count stable, or does it change? The 56 endpoints represent the current published catalog. New endpoints are additive — existing endpoints do not change their response shapes without a versioned deprecation cycle. For enterprise pipelines, pin your integration to versioned URLs and monitor the changelog.

What is the right answer when the platform does not cover a surface I need? Keep that call site with its current vendor. Partial consolidation — migrating three of five surfaces — still reduces key count, billing complexity, and on-call surface area meaningfully. Do not force a migration where it creates a feature regression.

Does consolidation affect my security review overhead? Yes, favourably. Most enterprise security reviews require a questionnaire, a data-processing addendum, and an annual review per vendor. Consolidating from five vendors to one converts five review cycles into one. For teams in regulated industries where each vendor review is a material audit commitment, this is often the strongest consolidation argument.

How do I handle the single-vendor dependency risk in my incident-response plan? Write a runbook for a total platform outage that includes graceful degradation: cached results served stale, non-critical location features disabled, critical features (ETA on a dispatch screen, address validation at checkout) failing fast with a user-friendly error rather than spinning. Test the runbook in a quarterly game day. A single vendor makes the runbook simpler to maintain, not unnecessary.

Related Articles

• The Real Cost of Running Your Own Geocoder — engineering overhead, infrastructure cost, and why the build vs. buy maths has shifted
• One-Week Geocoding Pilot Playbook — how to run a meaningful evaluation before committing to a new platform
• Migrating Geocoding Providers Without Downtime — the dual-write pattern that lets you cut over safely
• Benchmarking Geocoding APIs — Honest Numbers — what to measure in a parallel deployment and what to ignore
• Caching Geocoding Results — 90% Cost Reduction — how aggressive caching changes the cost maths on a consolidated platform

---

*I.A. / CSV2GEO Creator*