How to fix WP Store Locator Google Places API 403 errors

When WP Store Locator starts returning Google Maps or Places API errors, the plugin itself may not be the problem. In one WordPress troubleshooting case, every autocomplete request was failing with HTTP 403 responses even though the plugin was correctly configured to use Google’s newer Places API implementation.

The root cause was in Google Cloud. The browser API key was restricted to Places API (Legacy) but did not include Places API (New), while WP Store Locator was sending requests to the new endpoint. Adding Places API (New) to the browser key’s allowed APIs caused the error rate to fall immediately, and follow-up testing confirmed the store locator was functioning normally.

Issue background

A WordPress site using WP Store Locator began showing a 100% error rate for one of its Google API keys. Because Google Maps Platform usage was billable, the failed calls were especially concerning: requests were being generated, but they were not completing successfully.

The site had recently updated WP Store Locator to version 2.3.2, so the plugin update was initially considered as a possible cause. The team also reviewed other recent WordPress plugin and theme updates to determine whether anything had changed how the store locator loaded or authenticated Google Maps requests.

Diagnosis

The first step was to determine whether WP Store Locator was still using a legacy Google Places endpoint or had switched unexpectedly after the plugin update.

Reviewing the plugin and site configuration showed that WP Store Locator v2.3.2 supports both the legacy and new autocomplete implementations. The site was explicitly configured to use the new version:

wpslSettings.apiVersions.autocomplete = "latest"

This indicated that the plugin was intentionally attempting to use Places API (New), not silently changing behavior because of the update.

The browser console did not show the typical Google Maps authentication messages such as REQUEST_DENIED, ApiNotActivatedMapError, or RefererNotAllowedMapError. An unrelated 403 response for a marker asset was also present, but it did not explain the API billing failures.

Google Cloud’s normal Metrics interface only exposed the failed requests as general 4xx responses, which was not specific enough to identify the exact cause. The decisive test came from reproducing an autocomplete request in browser DevTools and inspecting the Network panel.

WP Store Locator was calling:

places.googleapis.com/$rpc/google.maps.places.v1.Places/AutocompletePlaces

Google returned HTTP 403 for every request.

That proved two things: WP Store Locator was correctly using the new Places autocomplete endpoint, and Google itself was rejecting the requests. The problem therefore pointed to Google Cloud API-key configuration rather than a defect in the WordPress plugin.

Resolution steps

A useful troubleshooting workflow for this type of WP Store Locator error is:

1. Confirm which Places API implementation the plugin is using. WP Store Locator can support different Google Places implementations. Check the plugin settings and frontend configuration instead of assuming a recent update changed the API automatically.
2. Inspect the browser console for Google Maps errors. Authentication messages can quickly reveal problems such as invalid referrers, disabled APIs, or rejected credentials.
3. Use DevTools Network when Google Cloud metrics are too vague. Filter network activity for places.googleapis.com while reproducing a store search or autocomplete request. The actual response can be more informative than a general 4xx chart in Google Cloud.
4. Verify the exact endpoint being called. In this case, the request targeted Google’s new AutocompletePlaces RPC endpoint, confirming that Places API (New) needed to be permitted.
5. Review API restrictions on the browser key. The browser key was configured to allow Places (Legacy) but not Places API (New). That mismatch caused Google to reject the plugin’s requests with HTTP 403.
6. Add the required API to the key’s restrictions. Places API (New) was added to the browser key’s allowed APIs in Google Cloud.
7. Monitor the error rate after the change. Shortly after the correction, the reported error rate dropped from 100% to 65%, showing that the change was taking effect.
8. Run a final functional test. Follow-up testing confirmed the store locator and autocomplete behavior were working normally.

The investigation also showed why it is important not to blame a recent plugin update simply because the timing overlaps. WP Store Locator v2.3.2 supported both API versions, and the choice between legacy and new autocomplete was controlled by configuration rather than being forced by the update.

Final outcome

The store locator issue was resolved by updating the Google Cloud browser key so it allowed Places API (New). The WordPress plugin did not require a rollback or replacement.

After the API restriction was corrected, Google stopped rejecting the autocomplete requests and the store locator returned to normal operation.

If WP Store Locator is producing HTTP 403 responses, 4xx errors, or failed Google Places requests, verify the API endpoint and key restrictions before changing the plugin. A browser key that permits only Places (Legacy) will not satisfy requests sent to Places API (New).

If you need help troubleshooting WP Store Locator, Google Maps Platform, Places API restrictions, or other WordPress API integrations, contact Freshy. Our WordPress team can help diagnose API-key configuration, HTTP errors, plugin integrations, and Google Cloud settings.