Google Business Profile API Quotas and Limits (2026)

If you have spent any time trying to automate something against Google's local ecosystem, you have probably run face-first into the wall that is google business profile api quotas. The Google Business Profile (GBP) API — formerly the Google My Business API — is one of the most heavily quota-limited and approval-gated products in Google's developer catalog. It is not a public data API. It is a management surface for businesses you already own or officially represent, and Google treats it that way at every turn: low default quotas, mandatory approval forms, strict rate limits, and a use-case review process that filters out anything that even smells like third-party scraping.

This guide walks through what the GBP API actually allows in 2026, what the quotas look like in practice, why it cannot be used for prospecting other people's businesses, and where a tool like MapsLeads fits in when you need lead data the API will never give you. Quotas and policies on Google's side change without much notice, so treat the specific numbers below as directional and always confirm against the current Google Business Profile API documentation before you build.

What the Google Business Profile API is for (managing YOUR listings)

The GBP API exists for one reason: letting business owners, agencies, and platforms programmatically manage the listings they are authorized to manage. That includes updating store hours, posting offers and events, replying to reviews, uploading photos, fetching performance insights, and synchronizing location data across many storefronts at once. If you run a 400-location restaurant chain, the GBP API is how you avoid manually editing 400 dashboards every time a holiday hour changes.

The mental model Google wants you to have is "remote control for listings I own." Every endpoint maps to something a logged-in business owner could do inside the Google Business Profile dashboard. Nothing more, nothing less. There is no endpoint to search for arbitrary businesses by keyword, no endpoint to pull a competitor's review history, no endpoint to dump every plumber in Phoenix. Those operations exist nowhere in the surface area of the API, by design.

Why it can't be used for prospecting (only for businesses you manage)

This is the single most common misunderstanding developers have when they first land on the GBP API docs. They read "Google Business Profile" and assume it must be the right way to get business profile data — names, phone numbers, websites, ratings — for outreach. It is not, and Google blocks that path on multiple levels.

First, every GBP API call is scoped to accounts the authenticated user has explicit ownership or management rights over. You authenticate with OAuth, and the only locations you can read or write are the ones attached to your verified accounts. You cannot query "all businesses in this city." You can only query "the businesses I manage."

Second, Google's API Terms of Service and the GBP-specific developer policies explicitly forbid using the API to harvest data about businesses you do not represent. Even if you found a creative way to fetch something, redistributing or repurposing GBP data outside the management workflow is a policy violation that will get your project suspended.

Third, the approval review process specifically asks for your use case in writing, and any answer that resembles "I want to build a lead-generation database" is rejected. The API is gated precisely so this does not happen.

If your goal is prospecting other businesses, the GBP API is the wrong door. We will get to the right one in a moment.

Approval and quota request process

You cannot just enable the GBP API in Google Cloud and start hitting endpoints at scale. The flow looks roughly like this. You enable the API in a Google Cloud project, configure OAuth credentials, and request access through the Business Profile API access form. Google reviews your application: who you are, what you are building, how many locations you manage, and whether your use case is a legitimate management scenario. Approval can take days or weeks, and rejections are common for vague or thin applications.

Once approved for basic access, you get the default quota. To raise it, you submit a separate quota increase request explaining why you need more, how many locations you manage, your projected QPS, and what error rates you are seeing. Google approves these case by case. Bigger quotas are reserved for partners and platforms with real volume — agencies managing thousands of locations, POS integrations, reputation management vendors with active customer bases.

For most independent developers, getting from "approved with default quota" to "actually high enough quota to ship a product" is a multi-week process that requires real traction or a real customer story.

Default quotas (low — must apply for higher)

The default quotas after approval are intentionally modest. Historically Google has seeded new projects with low daily and per-minute caps that are enough to test the API and serve a small handful of locations, but nowhere near enough to operate a real platform. Expect default ceilings somewhere in the low hundreds of QPM and a daily request budget that gets used up quickly if you are syncing many locations or polling insights frequently.

The exact numbers shift over time and per-account, so do not hard-code expectations. Always check your own Cloud Console quota page for the current values on your project. The pattern to plan for is: defaults are a starter allowance, real production traffic always requires a quota increase, and that increase is approved based on demonstrated need rather than just asking nicely.

Rate limits per minute / per project

On top of daily quotas, the GBP API enforces per-minute and per-project rate limits. Different endpoint families have different ceilings — read endpoints generally allow more QPM than write endpoints, and certain heavier endpoints (like media uploads or insight reports) have their own tighter caps. Hit any of those ceilings and you get HTTP 429 responses, which you are expected to handle with exponential backoff.

A few practical implications. Bulk operations need to be paced; you cannot fire off 10,000 location updates in a tight loop. Batch endpoints, where they exist, are your friend because one batched call costs less quota than the equivalent individual calls. And because limits apply per project, splitting one logical workload across multiple Cloud projects to bypass them is a policy violation, not a clever workaround.

If you are also working with Google Maps Platform, the quota mental model is similar but the products are separate — see Google Maps API limits explained for how those quotas interact with billing and request budgets.

What you can do with the API (post updates, fetch insights, manage locations)

Within those limits, the API is genuinely useful for the management use case. You can create and update locations, push hours and special hours, manage attributes, upload and remove media, publish posts (offers, events, updates), fetch and reply to reviews, fetch Q&A, and pull performance insights such as views, searches, and customer actions over time.

If you run an agency or build software for multi-location brands, this is the toolkit that lets you offer "we manage all your Google listings from one dashboard" without an army of interns clicking around. It pairs naturally with the kind of optimization work covered in optimize Google Maps listing for local SEO — once you know what good looks like, the API lets you enforce it across every location at once.

What you can't do (third-party scraping, mass data pulls)

Things the GBP API does not do, and will never do: enumerate businesses by category and city, return data on listings you do not manage, expose contact details of arbitrary businesses, provide bulk exports of competitor reviews, or stream "all businesses near a location" for lead-generation pipelines.

Any tutorial or Stack Overflow answer that claims otherwise is either describing the Places API (a different product) or describing a workflow that violates Google's terms. The hard separation between "manage what I own" and "discover what exists" is intentional, and Google enforces it through scope, approval, and policy.

When developers conflate GBP API with Places API (different products)

This conflation happens constantly. The Google Business Profile API and the Places API are different products with different purposes and very different quotas.

Places API is part of Google Maps Platform. It returns public information about places — name, address, phone, website, ratings, opening hours — for any place in Google's index, no ownership required. It is billed per request through Maps Platform pricing and capped by request budgets rather than approval gates. It is the closest thing Google offers to a public business data API, but it has its own restrictions: you cannot store most fields long-term, you cannot redistribute data outside Google-rendered surfaces in many cases, and it is priced for serving end-users in apps, not for building lead databases.

GBP API is for managing listings you own. No business search, no public data discovery.

If you read a forum post saying "use the Business Profile API to find competitors," the author meant Places API and got the names mixed up. They are not interchangeable.

When MapsLeads is the right tool instead

If your job is to find other businesses — to prospect plumbers in Houston, dentists in Lyon, or Shopify-using boutiques across a region — neither the GBP API nor the Places API is the right tool. The GBP API will not let you, and the Places API is priced and licensed for a different job (rendering places to end-users, not building a CRM).

MapsLeads is purpose-built for that prospecting use case. The flow is exactly what sales and lead-gen teams actually need. You open the search, type a query and a city — "roofers Denver", "veterinarians Madrid", "law firms Berlin" — and MapsLeads returns the list of matching businesses pulled from Google Maps results. From there you enrich exactly the records that look promising rather than paying for blanket data you may never use.

The credit model is simple and pay-as-you-go. The base record costs 1 credit. Add Contact Pro for 1 extra credit and you get the deeper contact layer — emails and decision-maker signals where available. Add Reputation for 1 extra credit and you pull review insight you can use to tailor outreach. Add Photos for 2 extra credits and you get the visual context that helps with personalization at scale.

You only pay for what you enrich. No quota approval forms, no OAuth dance for accounts you do not own, no policy review. It is the right shape for a sales workflow, exactly because it is not pretending to be a management API. For more on why a strong Maps presence matters on the receiving end of that prospecting, see benefits of Google Maps listing for local business.

FAQ

What is the GBP API quota? After approval, projects start with low default quotas — typically enough to test and serve a handful of locations, but not enough for production-scale management. Higher quotas require a separate request that Google reviews based on your use case and demonstrated need. Exact numbers vary and change over time, so check your Cloud Console.

Can I use the GBP API to scrape competitors? No. The API only returns data for accounts you have verified ownership or management of. There is no endpoint to search arbitrary businesses, and using the API to harvest third-party data violates Google's developer policies.

GBP API vs Places API — which do I want? GBP API is for managing listings you own. Places API is for displaying public place data to end-users in apps and websites. Neither is appropriate for building a sales prospect database; they are designed for completely different jobs.

What is a GBP API alternative for prospecting? For finding and enriching businesses you do not manage — the sales and lead-gen use case — MapsLeads is the right tool. It searches Google Maps by query and city, then lets you enrich with Contact Pro, Reputation, and Photos on the records you actually want.

How long does GBP API approval take? Anywhere from a few days to several weeks. Vague or thin use-case descriptions get rejected. Plan around the wait if you are building anything that depends on it.

Do GBP API limits apply across multiple projects? Yes in spirit — splitting a workload across projects to dodge quotas is a policy violation, not a workaround.

Conclusion

The Google Business Profile API is a precise, capable tool for the narrow job it was built for: managing listings you legitimately represent, at scale, through code. It is not a public data API, it is not a prospecting tool, and the quotas plus approval process exist specifically to keep it that way. Once you accept that framing, the limits stop feeling arbitrary — they are the shape of the product.

For everything the API will not do — finding businesses by category and city, enriching contact and reputation data on companies you do not own, building a real outbound pipeline — MapsLeads is the purpose-built alternative. Get started and run your first search in a couple of minutes.