Turn a point on the earth
into an answer you can use.
Give Salesforce a latitude and longitude, pick a curated layer (school district, council boundary, ferry corridor, census geography, or your own GeoJSON), and get back a clean JSON answer: what feature contains this point, what's nearest, or what's around it—without exporting spreadsheets or standing up a separate GIS stack.
Why this exists. The same "which district?" and "how close is the nearest...?" questions kept showing up in client work. I wanted a small, dependable service pattern teams could reuse—keys scoped to only the layers you need, responses shaped so Flow and Apex can actually use them, and documentation honest enough that you're not dependent on me for every tweak.
Inputs
lat = {!get_account.BillingLatitude} (47.611)
long = {!get_account.BillingLongitude} (-122.336)
service = KCSchoolDistricts
sType = near
{
"status_set": true,
"status": 200,
"properties_set": true,
"properties": {
"Shapex5fLength_set": true,
"Shapex5fLength": 435832.05730612075,
"Shapex5fArea_set": true,
"Shapex5fArea": 2570870909.3376207,
"SCHDST_set": true,
"SCHDST": 1,
"OBJECTID_set": true,
"OBJECTID": 1,
"NAME_set": true,
"NAME": "Seattle",
"DSTNUM_set": true,
"DSTNUM": 17001
},
"point_set": true,
"point": [-122.33649, 47.610615],
"fromx5fcache_set": true,
"fromx5fcache": true,
"distance_set": true,
"distance": 0,
"direction_set": true,
"direction": "Same location"
}
responseCode (200)At heart, it’s a spatial lookup: you send where you are (decimal degrees, the same coordinates you already store on accounts, sites, or program locations), name the dataset you care about, and the service returns the attributes of the matching boundary—or the nearest feature, with distance and direction when that’s the better question.
Each layer is a named service your organization is allowed to call. Nothing mysterious: your API key only unlocks the boundaries and public-data bridges you’ve been granted.
Lookup: inside or nearest
The everyday question is either “Which area serves this address?” (voting district, school district, program service area) or “What’s closest to this location?” (nearest ferry terminal, campus, trailhead). The API answers both from the same coordinates—pick the mode that matches the story you’re trying to tell.
Under the hood: one endpoint accepts familiar lat / long / service inputs, returns structured JSON with feature properties, optional distance and direction for “nearest,” and a cache hint so you know when the answer was reused for speed.
Good when
You already have geocoded addresses or lat/long on records and need to know it's relationship to a boundary to drive reporting, eligibility, or the next step in a Flow.
Service defined Schema (Swagger / OpenAPI)
Every dataset exposes its own machine-readable description of fields and shapes—so generated integrations (think Salesforce External Services) match what that layer actually returns, instead of guessing at property names after the fact.
Lookup, extract, and certain proxy bridges each have a documented URL pattern; you import the spec for the service you care about and wire it like any other REST contract.
Good when
Admins and partners who prefer “generate types, map fields, ship” over reading prose in a PDF.
Proxy: public geodata, Flow-shaped answers
For sources like the U.S. Census geocoder, raw responses can be wide, deep, and awkward for declarative automation. A proxy path normalizes selected responses into predictable buckets—collections you can loop in Flow, plus a “first row” shortcut when you only need the top match.
Optional host allowlists and GET-only routing keep the pass-through surface small; errors come back as JSON with a clear status, not an HTML surprise page.
Good when
You want census tracts, congressional districts, or similar public layers without maintaining your own copy of their pipeline.
If Salesforce is your system of record, the boring parts are still important: a Named Credential holds the base host and your ApiKey header so nothing sensitive is scattered through Flows; an External Service imports the Swagger for the layer you want; Flow (or Apex) calls the generated action like any other invocable.
I maintain a step-by-step operator guide for that path—duplicate URL pitfalls, how success payloads show up in Flow, and what to check when a callout returns HTML instead of JSON—because the goal is for your team to own the integration, not to rediscover those lessons one outage at a time.
At a glance
- ✓Auth: one header, one key, scoped services.
- ✓Lookup: containment or nearest from lat/long.
- ✓Extract: GeoJSON around a point within a mile radius you choose.
- ✓Docs: per-service OpenAPI for accurate imports.
Districts & reporting codes
Stamp the correct school, council, or legislative identifiers onto records for grants, mailings, and board-ready summaries—without manual spatial joins in a spreadsheet.
“Nearest” services & assets
Route people to the closest program site, transit link, or partner location; distance and direction come along when the story needs them.
Census & federal layers
Pull tract or district context from trusted public sources in a shape Flows can read—without maintaining your own copy of every geography release.
Eligibility & compliance checks
Ask containment questions against the same boundary file everyone agrees is authoritative, then let Salesforce handle the policy logic you define.
Radius pulls for maps & partners
Hand another system or experience a bounded GeoJSON slice instead of exporting your entire layer “just to be safe.”
Operational honesty
Clear errors, size guardrails, and cache transparency—so when something breaks, you’re debugging facts, not vibes.
Wondering if this fits your org?
Tell me what you’re trying to answer with geography—I'll be straight about whether this API pattern is the right leverage, what a sensible first layer would be, and what you can own without a long dependency chain.
Let's talk about what's possible