Same tile spec, different bill.
Vector tiles follow the same MVT spec and the style document follows the same schema, so the rendering side moves with a rename. The search and directions payloads differ more than the tiles do.
- MVT and style-spec compatible: your renderer stays
- Isochrone maps directly onto isolines, including consumption ranges
- Truck profiles included rather than a separate product tier
- Published rates rather than per-tier map-load bundles
The swap
Host and auth header. Everything below is the parameter map.
- https://api.mapbox.com?access_token=YOUR_TOKEN
+ https://api.apinavi.com
+ Authorization: Bearer $APINAVI_KEYParameter map
Search & navigation
| Mapbox | ApiNavi | Note |
|---|---|---|
| GET /geocoding/v5/mapbox.places/{q}.json | GET /v1/geocode?q= | — |
| GET /search/geocode/v6/reverse | GET /v1/revgeocode?at= | — |
| features[].place_name | items[].address.label | — |
| features[].center [lng,lat] | items[].position {lat,lng} | Axis order differs: GeoJSON positions are lng-first, our object is keyed. |
| GET /directions/v5/mapbox/driving | GET /v1/routes?transportMode=car | — |
| GET /directions-matrix/v1 | POST /v1/matrix | — |
| GET /isochrone/v1 | GET /v1/isolines | — |
Tiles & styles
| Mapbox | ApiNavi | Note |
|---|---|---|
| GET /v4/{tileset}/{z}/{x}/{y}.mvt | GET /v1/tiles/vector/{z}/{x}/{y}.mvt | — |
| GET /styles/v1/{user}/{style} | GET /v1/styles/{style} | Style JSON follows the same spec; layer ids differ. |
| GET /styles/v1/.../static/ | GET /v1/static | — |
Where it is not a drop-in
Axis order
Mapbox returns center as [lng, lat]. Our position is an object with lat and lng keys, which removes the ambiguity but needs a small adapter.
Style layer ids
Both follow the style spec, but layer ids differ. A fork of a Mapbox style needs its ids remapped — the docs list the equivalents.
Feature ids
Mapbox feature ids are not stable across data refreshes and neither are they interchangeable with ours. Re-resolve stored references.
Client-side navigation SDK
We ship routing APIs, not a turn-by-turn navigation SDK with voice guidance. That layer stays yours or stays theirs.
How teams usually do it
- 01
Shadow
Send a copy of production traffic to both providers for a week. No user-facing change.
- 02
Diff
Compare field by field on the endpoints you actually use. Most teams find two or three real differences, not twenty.
- 03
Split
Move 5%, then 50%, watching error rate and latency per region.
- 04
Cut
Flip the rest, keep the old key alive for a fortnight, then rotate it out.
Dual-run mode
Point a percentage of traffic at both providers and diff the responses. The console shows field-level disagreement rates per endpoint, so you cut over on evidence rather than on a spot check.
Leaving later
The same tables read in reverse, and an export endpoint returns your saved geofences, styles and batch results in open formats. A migration guide that only points inwards is a warning sign, not a feature.
Cutover checklist
- Rate limits raised on the new key before the split, not after
- Spend cap set for the first full month
- Saved place identifiers re-resolved if you store them
- Polyline decoder confirmed against a known route
- Coverage checked for the countries in the long tail of your traffic
- Old key rotated out and removed from secrets