Google Places API key setup: what to keep server-side

The first Google Places API setup mistake is treating an API key like a harmless public identifier. It is not. A key attached to a billable Maps project is a credential that can create spend.

Google’s own Places API usage and billing docs say you need billing enabled and an API key or OAuth token for API and SDK requests. The important implementation decision is where the credential lives.

The literal setup path

The setup flow is short:

1. Create or choose a Google Cloud project.
2. Enable billing for that project.
3. Enable the Places API you plan to call.
4. Create an API key or configure OAuth for supported server-to-server use.
5. Restrict the key before production traffic reaches it.

That last step is where most surprise-bill stories start.

Use separate keys for separate surfaces

If a browser map widget needs a Google Maps JavaScript key, give it a browser-restricted key. If your backend calls a web service, use a separate server-side key. Do not reuse one key everywhere just because it works during development.

Google’s API security best practices recommend storing API keys outside source code, restricting keys to the APIs they need, and using IP address restrictions for server-side applications that rely on API keys.

The practical setup:

1. Create a dedicated project or at least a dedicated key for server-side Places calls.
2. Restrict that key to the exact Maps APIs it needs.
3. For server-side calls, restrict by source IP where your infrastructure allows it.
4. Keep the key in your secret manager or deployment environment, not in Git.
5. Log request IDs and error codes, not full URLs with keys.

Do not put server-side search keys in client JavaScript

Place search looks easy to call from the browser. Because it is easy, the key ends up in the bundle, and a bundle is public. Anyone can inspect it, copy the key, and send requests until quota or billing controls stop them.

Browser restrictions help for browser products, but they are not a reason to put backend search credentials into frontend code. If the search is part of your product backend, route it through your backend:

export async function GET(request) {
  const { searchParams } = new URL(request.url);
  const lat = searchParams.get("lat");
  const lon = searchParams.get("lon");
  if (!lat || !lon) {
    return Response.json({ error: "lat and lon are required" }, { status: 400 });
  }

  const url = new URL("https://api.goodenoughmaps.com/v1/places");
  url.search = new URLSearchParams({
    q: searchParams.get("q") ?? "coffee",
    lat,
    lon,
    radius_mi: "10",
  }).toString();

  const response = await fetch(url, {
    headers: { Authorization: `Bearer ${process.env.GOOD_ENOUGH_MAPS_API_KEY}` },
  });
  return Response.json(await response.json(), { status: response.status });
}

The same shape applies to Google Places, Mapbox, or any other billable location API. The frontend asks your backend. Your backend owns the credential.

Restrict before launch, not after the bill

It is tempting to leave restrictions loose until launch. That is backward. Loose keys are easiest to forget when the prototype becomes production.

At minimum, restrict by API. A key intended for Places should not also call every enabled Maps service. For server-side keys, add source restrictions. For browser keys, add HTTP referrer restrictions, and understand their limits.

Google also recommends deleting unused keys and disabling unused services. That matters because a forgotten enabled API is still a surface area for abuse.

Where Good Enough Maps differs

Good Enough Maps avoids the browser-key question by design. The public Places API is a server-side API. It uses a bearer API key, and the expected path is:

1. User interacts with your app.
2. Your frontend sends normal product parameters to your backend.
3. Your backend calls Good Enough Maps.
4. Your backend returns the allowed result fields to the frontend.

That is less magical than a drop-in browser SDK. It is also easier to reason about, easier to rate-limit, and safer for a billable search feature.

FAQ

Do I need an API key for Google Places?

Yes. Google’s Places API docs state that requests require billing enabled and an API key or OAuth token.

Should a Places API key go in frontend code?

Not for server-side web service calls. Keep backend search keys on your server, restrict them to the APIs they need, and use browser-restricted keys only for browser surfaces that require them.

How does Good Enough Maps handle API keys?

Good Enough Maps uses server-side bearer keys. Keep the key in your backend environment and call Good Enough Maps from your server, not directly from browser JavaScript.

Last validated 2026-06-23.