Feature request: Ads API endpoints for location boundaries & “nearby” suggestions to match Google Ads UI

[עידן תבורי‎]

We operate a campaign builder for Search that lets advertisers select locations exactly like in the Google Ads UI (country/region/city/postal). We already sync the full GeoTargetConstant catalog (~226k IDs). Our source of truth is the GeoTarget IDs, not polygons.

Problem
There is no API to (a) retrieve the map boundaries used in Ads UI or (b) get “nearby/adjacent” location suggestions. The current APIs only expose IDs and names. Maps JS Feature Layers (DDS) are great for visualization but don’t allow exporting geometry or programmatic matching to Ads GeoTargets. As a result:
- We can’t show “show all areas” and click-to-select on a map that matches Ads coverage.
- We can’t offer “Add nearby locations” automatically like the Ads UI does.
- Postal Code coverage is inconsistent by country and not discoverable via API.

Why existing APIs are insufficient
- GeoTargetConstantService: no geometry/boundaries, no adjacency graph, no country-by-type coverage endpoint.
- CampaignCriterion/LocationInfo: accepts IDs only (expected), but no assistance for discovery/nearby.
- ProximityInfo: radius targeting solves a different need (not an administrative/postal polygon).
- Maps DDS: visualization-only; cannot export polygons or map them to Ads GeoTarget IDs reliably.

Requested capabilities (any of the following would solve our problem)
1) Coverage endpoints
   - GET /vX/geoTargets/coverage?country=IL
     -> { supportedTypes: ["COUNTRY","REGION","CITY","POSTAL_CODE"] }
   - GET /vX/geoTargets/types
     -> matrix of countries × supported target types

2) Polygon/centroid access (minimal)
   - GET /vX/geoTargets/{id}/centroid
     -> { lat, lng, source, updatedAt }
   - GET /vX/geoTargets/{id}/shape
     -> returns either:
        a) a signed URL to a GeoJSON/TopoJSON,
        b) or a tile endpoint (vector tiles) + feature metadata including the GeoTarget ID
     (Read-only; caching allowed; no Places lookups needed.)

3) “Nearby / Adjacent” suggestions
   - POST /vX/geoTargets:nearby { ids:[…], level:"CITY", maxDistanceKm:50, country:"IL" }
     -> [{ id, distanceKm }] ordered by proximity, equivalent to Ads UI behavior.

4) Mapping to Maps Feature Layers
   - GET /vX/geoTargets/{id}/placeId
     -> { placeId } if an internal mapping exists, so we can light up the correct polygon in DDS.

Non-goals & compliance
- We don’t need Places or POIs. Only administrative/postal targeting identical to Ads.
- We only display geometry for UX; we always send Ads the official GeoTarget IDs.
- Happy to follow rate limits, caching headers and any attribution requirements.

Impact
- Enables parity with the Ads UI for location selection.
- Reduces support load from advertisers confused by differences between third-party tools