What are the restrictions shown when visiting https://dashboard.algolia.com/account/api-keys/restricted?applicationId=YOURAPPLICATIONHERE ?
Fill in the actual application ID for that URL. We’re wanting specifically the “Search-only API Key”
Thank you for your prompt reply.
For the search API key the restrictions are: search, listIndexes, settings & browse.
Hmm.
Part of the validation process occurs in https://github.com/WebDevStudios/wp-search-with-algolia/blob/2.11.3/includes/class-algolia-api.php#L195-L244
4 spots that it maybe returns false.
- Error with fetching the key as a whole, with an AlgoliaException
- “search” scope is NOT set.
- The key has more permissions than we allow (the four you listed, and recently added
browse with one of our latest releases)
- If the key has unlimited TTL (we don’t want unlimited).
Based on the original error message, we’re hittting the first one, for some reason.
Have you done any customization to configurations? Specifically items that would be set in https://github.com/WebDevStudios/wp-search-with-algolia/blob/2.11.3/includes/factories/class-algolia-search-client-factory.php like secured keys?
No, I don’t believe there are any customization to configurations. I just put error logs between the last conditional and the last return statement of that file and it accurately logged my app ID and my API Key when I attempted to save changes. Perhaps I’m missing a better way to verify.
For clarity, after the conditional block starting with if (!empty($custom_config) && is_array($custom_config)) and before the final return statement in the file I put:
error_log('Creating Algolia Search Client with App ID: ' . $app_id);
error_log('Creating Algolia Search Client with API Key: ' . $api_key);
Also, just to give you as much info as possible, I noticed that my Admin API Key is not listed under “All API Keys”, which seemed odd to me. Is this expected?
Did anything get logged for that?
Regarding “All API Keys” listing, I assume this to be expected, but we have zero control with what shows there. That’s an Algolia.com question.
Out of extra curiosity, have you reached out to Algolia support regarding this? They may be able to help deduce why the app/api pairings aren’t validating, or at least if they SHOULD.
I still believe we’re likely failing at a spot with this:
try {
$acl = $client->getApiKey( $search_api_key );
} catch ( AlgoliaException $e ) {
return false;
}
Which is a step that includes their PHP SDK
It’s failing in the code below, in class-algolia-admin-page-settings.php. I can do a curl request with the admin API key and App ID and get results. I’ll contact Algolia. I really appreciate your help in narrowing down the issue.
try {
Algolia_API::assert_valid_credentials($settings->get_application_id(), $value);
} catch (Exception $exception) {
$valid_credentials = false;
add_settings_error(
$this->option_group,
'login_exception',
$exception->getMessage()
);
}
Definitely both on the same right paths. The try/catch I pointed out earlier is part of the Algolia_API::assert_valid_credentials() call. Just different spots in the stack trace 😀
I figured as much. I’ll let you know what Algolia says. Thanks again for all your help.
@tw2113, can you please provide the Algolia PHP SDK version the plugin is using? I am talking to a rep from Algolia and they needed it for troubleshooting.
@bdbowles we currently ship with "algolia/algoliasearch-client-php": "3.4.2" from Composer.
@tw2113 here is the response from Algolia support:
Thanks for sending over those details.
Based on the information you provided, the fact that the curl request succeeds against the Algolia API strongly suggests that:
• the Application ID is valid,
• the API key is valid,
• and the Algolia platform is reachable from your environment.
Given that, the issue appears more likely related to the integration layer itself, specifically:
• how the WordPress plugin is validating credentials,
• how the SDK exception is being handled,
• or a compatibility issue between the plugin and the runtime environment.
One thing that stands out is the environment combination:
• WP Search with Algolia 2.11.3
• PHP 8.4.11
• Algolia PHP client 3.4.2
At this stage, the most useful next step would likely be for the plugin maintainers to inspect:
• the exact request being made during assert_valid_credentials,
• whether any lower-level SDK exception is being suppressed and replaced with the generic “Impossible to connect” message,
• and whether the plugin has been validated against PHP 8.4 specifically.
I also wanted to note that the PHP client version you mentioned, algolia/algoliasearch-client-php 3.4.2, is the latest release of the v3 client line and remains within our supported window under Algolia’s support policy. However The latest stable version of the Algolia PHP API Client is 4.43.0, released in May 2026.
You should not need to provide a standalone reproduction script right now, especially given your internal restrictions.
For reference:
https://www.algolia.com/policies/support
https://www.algolia.com/doc/libraries/sdk
If the plugin maintainers are able to capture the underlying SDK exception, request debug logs, or HTTP response details, feel free to share those with us and we’ll be happy to investigate further from the API client
side.
So the assert_valid_credentials method can be found at https://github.com/WebDevStudios/wp-search-with-algolia/blob/2.11.3/includes/class-algolia-api.php#L195-L244
Would be interesting to:
- verify the 2 parameters are coming in as expected.
- Add a log line in the catch block for
$client->listApiKeys() call
- Verify the
$client->getApiKey( (string) $api_key ); call is what we’re expecting based on dashboard values. Maybe use a try/catch around that as well.
- Check if we get to the
if ( ! empty( $missing_acls ) ) { ... } section where we throw our own exception.
- Verified, credentials are as expected.
- throws an exception with the message: “Impossible to connect, please check your Algolia Application Id.”
- used a try/catch, throws the same exception
- never get to here
So, the Algolia_Search_Client_Factory isn’t getting created as expected?
