Placekey

@Placekey get the Placekey for 1600 Amphitheatre Parkway, Mountain View, CA 94043

The Placekey for that address is `222-227@5vg-7gq-tvz`. This identifier consists of two parts: the 'What' part (222-227) represents the specific building, while the 'Where' part (5vg-7gq-tvz) represents the geographic area. You can use this Placekey to match this location across different datasets, deduplicate records, or join spatial data without worrying about address formatting inconsistencies.

This example shows address-to-Placekey conversion, the core use case for location standardization. Requires a valid API key with sufficient quota. The Placekey format is deterministic—the same address always produces the same identifier, making it reliable for data joins across systems.

@Placekey what are the coordinates for 350 Fifth Avenue, New York, NY 10118?

The geocode for that address is latitude 40.748440, longitude -73.985664. This corresponds to the Empire State Building in Midtown Manhattan. The Placekey API resolved the street address through its geocoding service, which normalizes address formatting and returns WGS84 coordinate system values suitable for mapping applications or spatial analysis.

Demonstrates geocoding capability for converting addresses to lat/long pairs. Useful when you need coordinates for mapping or distance calculations but don't need the Placekey identifier itself. Accuracy depends on address completeness—ambiguous addresses may return approximate coordinates.

@Placekey I have coordinates 37.7749, -122.4194—get me the Placekey and then explain what geographic area that 'Where' portion represents

The Placekey for those coordinates is `@5vg-7gq-qzk`. The 'Where' part (5vg-7gq-qzk) represents a hexagonal area roughly 15,000 square meters in San Francisco's downtown area. Placekey uses H3 hexagons at resolution 10 to encode geographic locations, which means any point within this hex will share the same 'Where' identifier. This is particularly useful for aggregating location data—multiple businesses in the same block might share this 'Where' code while having unique 'What' parts for their specific addresses.

Shows coordinate-to-Placekey conversion and highlights the hexagonal grid system underlying Placekey's design. The 'Where' part alone (without a 'What' part) indicates a geographic area rather than a specific building. Understanding this distinction is critical when using Placekeys for spatial joins or proximity analysis.

When Placekey beats raw addresses for multi-stop scheduling

A 6-person HVAC company runs 20-30 service calls daily across three zip codes. Their dispatcher uses a spreadsheet with customer addresses that often have typos, missing suite numbers, or duplicate entries for the same building. Placekey's address-to-ID tool solves this by converting each address into a stable identifier that survives formatting inconsistencies. The dispatcher can dedupe jobs at the same location, group nearby stops, and pass clean coordinates to routing software without manual cleanup. This works because Placekey normalizes addresses server-side and returns both the ID and lat/long in one call. The break-even is around 15 stops per day—below that, manual address fixing is faster than setting up the API key and building the workflow. If your team runs routes daily and addresses come from multiple sources (CRM, email, phone), Placekey cuts 10-15 minutes of prep per dispatch cycle.

How Placekey dedupes property records without geocoding every address

A 3-person commercial real estate team tracks lease comps across 200+ buildings in two metro areas. They pull data from CoStar, LoopNet, and broker emails—each source formats addresses differently, and the same building appears under five variations. Placekey's address converter creates a single ID per property, so the team can merge records in their spreadsheet without writing fuzzy-match logic or paying for a geocoding service per lookup. The lat/long output also lets them map comps in Notion or Airtable without a separate geocoding step. This is overkill if you track fewer than 50 properties or work in a single neighborhood where you recognize every address by eye. But if you're aggregating data from multiple listing sources weekly, Placekey's 3-tool setup is faster than building address normalization in-house or subscribing to a full GIS platform.

When coordinate-to-Placekey helps compare foot traffic datasets

A 4-person growth team at a regional coffee chain evaluates 10-12 potential storefront locations per quarter. They buy foot traffic data from SafeGraph and demographic reports from Esri, but the datasets use different location identifiers—one uses lat/long pairs, the other uses proprietary place IDs. Placekey's coordinate converter creates a common key so they can join the datasets in a single spreadsheet without manual lookups. The team runs this once per site evaluation cycle, not in real-time, so the 3-tool MCP is enough (they don't need bulk geocoding or reverse lookups). This stops being useful if your datasets already share a standard ID or if you're only comparing 2-3 sites per year. But if you're merging location data from multiple vendors monthly and need a lightweight way to align records, Placekey's coordinate tool is the fastest path to a joined table.