Subject: Toolset Maps 2.2.4 – testAPIVersion() sends a billable "Phoenix" Autocomplete request on every address field initialization
What I expected to see:
Opening a page that contains Toolset address fields or a distance filter should not send billable Places API requests before the user types anything.
What I got instead:
Every page load sends one or more billable AutocompletePlaces requests to Google before any user input. The fields are empty and untouched.
Details:
In jquery.geocomplete.min.js, testAPIVersion() sends a real autocomplete request for the literal string "Phoenix" with a fresh AutocompleteSessionToken, purely to check whether the API responds:
const request = { input: "Phoenix", sessionToken: new google.maps.places.AutocompleteSessionToken };
const { suggestions } = await google.maps.places.AutocompleteSuggestion.fetchAutocompleteSuggestions(request);
The result is cached in this.isAPITested – but that flag lives on the individual instance, not globally. Every address field probes again, and every re-initialization probes again.
Measurements on my site (Toolset Maps 2.2.4, WordPress 6.9.7, Google Maps API with new Places API):
- Page with 1 distance filter: 1 request on load
- Page with 1 address field (hidden, conditional): 2 requests on load
- Post form with 2 address fields: 6 requests on load
All requests fire in the same millisecond window, immediately after places_impl.js loads. The console shows "Testing new AutocompleteSuggestion API..." once per probe, followed by "New AutocompleteSuggestion API is working - using new API".
Billing impact:
Over 30 days my project logged 12,074 Places API (New) requests against 2,488 Maps JavaScript API loads – roughly 4.9 requests per page view. On a single day, 875 autocomplete requests corresponded to only 19 Place Details calls, so around 98% of the autocomplete requests never led to a selected address.
Each probe also opens a fresh session token that is never completed with a Place Details call. It is therefore billed under the "Autocomplete Requests" SKU (USD 2.83 per 1,000) rather than as part of a session, which would be free when properly terminated.
The probe cannot be intercepted on archive pages:
On post forms I can patch fetchAutocompleteSuggestions before Toolset re-initializes, because the field initialization runs a second time after our consent handler. On archive pages with a distance filter there is no second initialization: Toolset calls testAPIVersion() synchronously from the Maps JS callback, in the same execution turn. I moved my patch from wp_footer to wp_head – measured script position 26 versus Google Maps at position 129 – and the probe still went through. There is no point in the page lifecycle where a site owner can prevent it.
Practical consequence:
Because of this I had to hide the distance filter behind an "activate location search" button so that the address field is not rendered at all until the visitor asks for it. This is a worse user experience, and it exists only to avoid a request that no user triggered.
Suggested fix:
Cache the API version test result globally – for example in sessionStorage or on a module-level variable – so the probe runs at most once per page load instead of once per field instance. Better still, skip the probe entirely and fall back to the legacy API only when a real user request fails.
Environment:
Toolset Maps 2.2.4, WordPress 6.9.7, Google Maps API with new Places API enabled, browser key restricted by HTTP referrer.
