How to Locate API and CX for Lega Search with Google

For Google Cloud / Google Enterprise accounts, you generally manage API keys the same way as anyone else, but there are a few differences and extra options available to you because of the enterprise setup.

Specifically for the Custom Search JSON API:

1. Where API keys are managed

• All API keys (including for Custom Search) are created and managed in the Google Cloud Console → APIs & Services → Credentials.
• This process is the same for enterprise and non-enterprise users.

2. Enterprise account differences

With an enterprise account, you might have:

• Organization-level policies – your org admins may restrict how/where keys can be created or used (e.g., requiring service accounts instead of API keys, or enforcing restrictions).
• Billing/project structure – API usage must be tied to a Google Cloud project, and enterprise setups often enforce centralized billing.
• Key restrictions – enterprise policies may also require you to set:
  • API restrictions (limit the key to only Custom Search JSON API).
  • Application restrictions (IP addresses, HTTP referrers, Android/iOS apps).

3. Custom Search JSON API specifics

To turn on web search capabilities in Lega using Google search, you’ll need two things:

• An API key (managed in Google Cloud Console)  
• A Custom Search Engine (CX) identifier (managed at https://programmablesearchengine.google.com)
  • Enterprise vs. non-enterprise doesn’t change this – you still need both.
  • What can differ is quota: enterprise accounts can often negotiate higher query limits beyond the default 10k/day. We encourage you to reach out to your Google Account representative to confirm your options.

4. Best practices for enterprise accounts

• Don’t hardcode keys – store them in a secure secrets manager (Google Secret Manager, Azure Key Vault, etc.).
• Restrict keys – always apply API and application restrictions.
• Monitor usage – enterprise accounts often integrate with Cloud Monitoring/Logging.
• Consider service accounts – if building a backend app, sometimes using OAuth 2.0 with a service account is preferable to a raw API key.