Summary

  • Google’s Places API (New) documentation says an Autocomplete session ended with Place Details Essentials (IDs Only) bills every Autocomplete call individually, although the terminating details call is free.
  • With ordinary Place Details Essentials, the first 12 Autocomplete calls are billed individually and calls from the thirteenth use a no-charge session SKU; the details call has its own charge. The complete request sequence decides the bill.

The zero on the last line

Picture a location search box that offers suggestions as someone types. The application needs the selected place’s ID, not an address or other details. Its engineer sends Autocomplete (New) requests with a session token and finishes with a Place Details (New) request asking for IDs Only. That final request is free. The pleasant zero is at the bottom of the invoice, where a reader might stop looking.

Google’s session-pricing document assigns the earlier requests a different fate. An IDs Only terminator makes all Autocomplete requests billable one by one under Autocomplete Requests, as though the session had never existed. The token still groups the calls operationally. It does not earn the pricing treatment that some teams may associate with a completed session.

The contrast is unusually precise. End with ordinary Place Details Essentials and the first 12 autocomplete requests are billed individually; later calls fall under no-charge Autocomplete Session Usage. The ordinary details request is billed separately. End with Pro or Enterprise details, or Address Validation, and Google describes a no-charge session-usage treatment for all Autocomplete calls, while the terminating request takes its corresponding higher-priced SKU. A free terminator and a free journey are different products.

That distinction makes a field mask a purchasing decision. The person optimising response payload may want only an ID. The budget holder may look at a “session” count and assume the token has capped autocomplete exposure. Google’s rule puts the price hinge at the final request’s field selection. To compare designs, the buyer needs the number of autocomplete calls, the terminating SKU and the actual price terms for each complete path. Google’s documents contain no customer-specific request mix or invoice from which to announce a universal winner.

The token rules add another trap. Google says a new token is required for each session. Reusing one, omitting it, mixing Legacy and New sessions, or using keys from different Cloud projects breaks the intended session treatment. An abandoned session also leaves its autocomplete requests billed individually. In a production audit, classify endings and token validity separately; both can produce per-request charges, for different reasons.

Google made the ID free and left the journey metered. The useful question for an API buyer is therefore not “Was the last call free?” It is “Which event ended the session, and what happened to every call before it?”

Sources