Skip to main content

Search-only API keys on mobile

When running your app with the search only key embedded in your app, you might notice the following warning:
Warning: If you are building a native app on mobile, be sure to not include the search API key directly in the source code. You should instead consider fetching the key from your servers during the app’s startup
This approach follows the mobile security recommendations as people can potentially have access to this key. Moreover, having your key on your server gives you more flexibility as you would be able to make changes to it if needed without having to deploy a new app version to the AppStore.

Implementation

Store your API key on a remote server, then fetch it with a network request when the app starts. You can implement this with many server or serverless setups and in most backend programming languages. For an example, see this tutorial about getting API secrets from a server.

Secured API keys

As described in the previous section on Search Only Keys, mobile applications represent significant security risks to your API keys, and the inflexibility of mobile applications make secure operations more difficult. API keys shouldn’t be hardcoded in shipped mobile applications. Always fetch them dynamically from the application backend. The reason behind this recommendation is that users might not update your application as often as you want. When you rotate your API key as part of the security workflow, or the key leaks and you need to revoke it, the installed application stops working. Keep in mind that the application, which might look secured, can be easily opened by existing tools and your API keys extracted from it. Therefore, don’t give your mobile application API keys more privileges than is necessary and use Secured API keys with expiration times.
Last modified on February 10, 2026