The Google Business Profile API developer playbook
The old My Business API is gone. What replaced it is a set of separate APIs, an OAuth flow, and an access request you have to be approved for. Here's how the pieces fit, what each API does, and where it makes more sense to rent the integration than to build and maintain it.
// Business Profile APIs use OAuth 2.0, not an API key
const headers = {
'Authorization': `Bearer ${accessToken}`,
'Content-Type': 'application/json'
};
// Each function is its own API host:
const res = await fetch(
'https://mybusinessbusinessinformation.googleapis.com/v1/locations/12345',
{ headers }
);
const location = await res.json();
// accounts -> mybusinessaccountmanagement.googleapis.com
// reviews -> mybusiness.googleapis.com/v4
// performance -> businessprofileperformance.googleapis.comThere isn't one Google Business Profile API
For years there was a single Google My Business API that did everything. Google retired it. The monolithic v4.9 was fully sunset in April 2022, and anything still calling those old endpoints simply stopped working. What replaced it is a federated set of smaller APIs, each with its own host and version, each shipping on its own schedule.
The naming adds to the confusion. The product is now called the Business Profile APIs, but several of the hosts still read mybusiness.googleapis.com, and most tutorials online were written for the old structure. If you're reading a guide that shows one base URL for accounts, locations, reviews, and posts together, it predates the split and won't run.
So the real first task isn't writing a request. It's knowing which API owns the thing you want to touch, getting access to it, and keeping up as Google moves pieces around. That's what the rest of this page walks through, and it's also why a lot of teams decide the integration isn't worth owning.
The APIs you'll actually wire up
Each function lives behind its own host and version. You enable the ones you need in a Google Cloud project, and most real integrations touch several at once.
Hosts and versions move. The Business Profile APIs overview is the source of truth before you build against any of them.
Access is an application, not a signup
This is the part that surprises people. A new Google Cloud project starts with zero quota on the Business Profile APIs. You can enable them and authenticate, but calls return nothing useful until Google raises your quota, and that takes a formal request you have to be approved for.
The request asks you to show a real business reason. Google looks for a verified profile that's been active for a couple of months, a business website on a matching domain, and a clear description of the workflows you intend to run, like managing locations or monitoring reviews for clients. Thin or vague applications get turned down, and approval doesn't light up every endpoint at once.
So the build path starts before any code: create the Cloud project, enable the right APIs, set up the OAuth consent screen, then apply and wait. Plan for that lead time. The prerequisites and access request guide is where the current requirements live.
OAuth, tokens, and the part you maintain
The Business Profile APIs use OAuth 2.0, not a static key. A profile owner or manager signs in through Google's consent screen and grants your app the business.manage scope. You get back an access token that expires in about an hour and a refresh token you store to mint new ones.
That refresh token is the thing you have to look after for the life of the integration. It can be revoked if the user removes access, it can be invalidated if their Google password changes, and you need somewhere safe to keep it per connected account. For a product serving many businesses, that's a real piece of infrastructure: secure storage, refresh handling, and a path to re-consent when a token stops working.
None of it is exotic. It's the standard cost of a per-user OAuth integration, multiplied by every location you connect. Worth knowing up front, because it's ongoing work, not a one-time setup.
What's been turned off, and what replaced it
A federated model means Google can retire one API without touching the others, and it does. If you build against these, watching the deprecation schedule is part of the job. A few of the bigger recent changes:
The pattern matters more than any single line item. Endpoints you depend on can change host, version, or behavior, and the work of keeping a live integration current never really stops. Google's deprecation schedule is the page to keep bookmarked.
Reading profile performance
Metrics moved out of the old insights methods and into the Business Profile Performance API. You ask for a daily metric over a date range and get back a time series. The metrics cover how people find and act on a profile: searches, calls, direction requests, website clicks, and impressions on the posts you publish.
One thing to plan for is history. The API serves a rolling window, so if you want trend lines that go back further than Google keeps, you pull the daily values on a schedule and store them yourself. That local copy is what powers month-over-month reporting, and it's the same storage pattern whether you build it here or pull the numbers from a platform that already keeps them.
What you're really deciding
Building directly on Google's APIs is the right call when Google is the whole job and you want full control: you own the access request, the OAuth token lifecycle across every connected account, and the maintenance as endpoints shift. For a team whose product is Google Business Profile management, that ownership is the point.
The catch is that all that work buys you one network. Google is where you start, but local presence also lives on Apple, Bing, Facebook, and a long tail of directories, each with its own access model or no API at all. Build the Google integration and you've solved a fraction of the surface, then face the same effort again for the next source.
Renting flips that. Synup already holds the publisher relationships and exposes them behind one API key and one response schema. You write a location once and it syncs to Google and the rest of the network. Reviews, rank, and analytics come back through the same key, and the access requests, OAuth plumbing, and deprecation chasing sit on Synup's side. You get the result without owning the integration.
Google Business Profile API FAQs
Common questions on what replaced the old API, how access works, and when to build on Google directly versus through a platform.
Is the Google My Business API still available?
No. The monolithic My Business API v4.9 was sunset on April 30, 2022. It was replaced by the federated Business Profile APIs, where each function has its own host and version. Some of those hosts still read mybusiness.googleapis.com, which is why the old name lingers.
How do I get access to the Business Profile APIs?
A new Google Cloud project starts with zero quota. You enable the APIs, set up OAuth, then submit a formal access request with a real business use case, a verified profile active for 60+ days, and a matching business website. Google raises your quota once it approves the request. See Google's prerequisites
Does the API use an API key or OAuth?
OAuth 2.0. A profile owner or manager consents through Google and grants the business.manage scope, and you handle the access and refresh tokens per connected account. There's no static API key for this one.
Does the Google API cover listings beyond Google?
No. It only manages Google Business Profile. Apple Maps, Bing Places, Facebook, and other directories each need their own integration. A platform like Synup covers Google and the wider network behind a single key.
How is this different from using Synup?
Synup sits on top of Google and the rest of the directory network, so you write a location once and it syncs everywhere, with reviews, rank, and analytics through the same API key. The access requests, OAuth plumbing, and deprecation maintenance are handled for you.
Skip the build, keep the result
Get a Synup API key and manage Google Business Profile and the rest of the directory network behind one schema. We'll provision a sandbox so you can test against live data before any sales call.