B2B Revenue Autopilot Kit

Operational security · 20 October 2026 · 9 min read

The one part of your prospecting stack that can bill you while you sleep is the API key

A broken n8n workflow returns zero rows and you notice. A badly fenced API key does not warn you: it pays. This is what we do before importing any workflow that touches Google Places and DeepSeek —restrictions, quota caps, budget alerts and a three-request test— using the Places tiers and prices read from the official global price list on 20 October 2026.

1. What actually breaks: the order of the facts

A prospecting install has three assets and only one of them carries financial risk:

And there is a detail that surprises almost everyone: Google requires a linked card even to use its free tier. With billing inactive the key answers 403 with REQUEST_DENIED, and the workflow looks broken when it is simply not enabled. So the correct order is: billing → API enabled → key restricted → quota cap → and only then import.

2. The real Places free tier (verified today, not from memory)

Google Maps Platform's global price list, read on 20/10/2026, shows the free cap per SKU per month, not a single account-wide allowance. For Places API (New), the rows that matter for prospecting are these (USD per 1,000 requests, first tier):

SKUFree per monthPer 1,000 requests
Text Search Essentials (IDs only)unlimited0.00
Text Search Pro5,00032.00
Text Search Enterprise1,00035.00
Text Search Enterprise + Atmosphere1,00040.00
Place Details Pro5,00017.00
Place Details Enterprise1,00020.00

The practical consequence: if your field mask asks for a phone number or a website, the request bills as Enterprise —35.00 USD per 1,000— and you get 1,000 free requests a month, which at 20 results per page is in the order of 20,000 businesses. A daily run of 60 prospects spends 3 requests: USD 0.105. We measured it; that is what a real run of our kit cost.

We also note the honest alternative, because it is cheaper: Text Search IDs only (free, unlimited) to get the placeIds, then Place Details Enterprise (1,000 free, 20.00 USD per 1,000). That works out at USD 1.00 per 1,000 leads instead of 1.75. It is not the kit's default path because it means two requests per page instead of one: it doubles the failure surface, the latency and the places where a retry is needed. When volume justifies that saving, the change is documented and it is an edit to the field mask and the node, not a rewrite.

3. Fencing the Google key in five steps

  1. Project and billing. Create a project just for this and link the card. The free tier exists, but billing must be active.
  2. Enable the right API. In the library search for Places API (New) —the one that says “(New)”, not plain “Places API”— and enable it. They are different APIs with different quotas and different responses; this is the number one setup mistake.
  3. Restrict the key by API. In the key, under API restrictions, tick only Places API (New). If that key leaks, it cannot spend on Maps, Routes or Gemini.
  4. Application restrictions: it depends where n8n runs. On n8n Cloud there is no fixed IP, so leave it as “None” and compensate with quotas and alerts. Self-hosted with a fixed IP: restrict by IP, and any use from elsewhere returns 403.
  5. Quota cap and budget alert. Under Quotas, set a daily maximum for Text Search while you test (200 requests/day is a reasonable seatbelt). Separately, under Billing → Budgets and alerts, set a 1 USD alert at 50/90/100 %. The cap stops the tap; the alert tells you before the card does.

4. DeepSeek: prepaid, and why that changes the risk

DeepSeek runs on prepaid balance: you top up, say, 5 USD and there is no way a leaked key can charge more than that balance. That makes it structurally safer than a bearer-card API. What is still worth doing:

5. The three-request test (60 seconds, before importing)

Having a key is not the same as having it fenced. These three requests —by hand, with curl— separate the three failure modes that later get mistaken for “the workflow doesn't work”:

# 1) Does the key exist and is the API enabled? Expect: 200
curl -s -o /dev/null -w "%{http_code}\n" \
  "https://places.googleapis.com/v1/places:searchText" \
  -H "Content-Type: application/json" \
  -H "X-Goog-Api-Key: $PLACES_KEY" \
  -H "X-Goog-FieldMask: places.id,places.displayName" \
  -d '{"textQuery":"dentists in Providencia, Santiago","pageSize":1}'

# 2) Is the expensive field allowed for this key? Expect: 200 (billed as Enterprise)
#    Swap the FieldMask for: places.id,places.displayName,places.nationalPhoneNumber,places.websiteUri

# 3) Does the per-API restriction hold? Expect: 403 PERMISSION_DENIED
curl -s "https://maps.googleapis.com/maps/api/geocode/json?address=Santiago&key=$PLACES_KEY" | head -20

If #1 returns 403 REQUEST_DENIED, billing is missing or the API is not enabled. If it returns 400 with a mask message, the problem is the FieldMask, not the key. If #3 returns 200, your key is not restricted per API: go back to step 3.

Inside the kit you don't do this by hand: scripts/selftest.sh calls both services with your .env keys and prints OK or FAIL with the exact HTTP code before you import anything. Fixing keys there removes 90 % of later diagnosis.

6. What you never do

The kit ships the self-diagnostic that validates both keys, the first-month spend-cap recipe and every Places HTTP code explained one by one. See what's inside →