Developers waiting for access to the Google Business Profile APIs may be waiting considerably longer than expected. Google says it is dealing with an unusually high volume of access applications, which has extended processing times, and the company currently cannot provide an estimated timeframe for applications that are still pending.
The delay was reported by Search Engine Roundtable on September 15. Google’s guidance to applicants is unusually simple: if an access request is already under review, do not submit another one.
For agencies, local-search software companies and multi-location platforms, the backlog can create a real implementation bottleneck. The Google Business Profile APIs are the programmatic layer used to manage profile and location information at scale, but they are not public APIs that any Cloud project can immediately enable. Google reviews access applications before granting a project permission to use them.
Google says request volume is unusually high
The immediate problem is application processing rather than an outage in the APIs themselves.
Google says the volume of requests for API access is currently higher than usual and that this has resulted in longer review times.
The company has not published the size of the backlog, the average current wait or a date by which pending applications should be cleared.
That uncertainty is the key operational issue. Teams can plan around a documented approval window; they cannot easily plan around an open-ended queue.
There is currently no ETA for pending applications
Google’s existing Business Profile API FAQ has historically said access requests are reviewed within 14 days.
The current backlog notice effectively makes that baseline unreliable for applications already caught in the queue. If Google says it cannot provide an estimated timeframe, developers should not treat the 14-day language as a guaranteed current service-level agreement.
This does not mean every application will take dramatically longer than two weeks. It means Google is not committing to that schedule while the unusually high volume continues.
Teams with launch deadlines should build that uncertainty into their project plans.
Do not submit a second application while the first is pending
Google specifically recommends against sending additional access applications when the original request is still under review.
Submitting duplicates may feel like a way to restart or escalate a stalled request, but Google’s current guidance says not to do it.
The correct response to a pending application is therefore to wait for the existing review rather than create parallel requests for the same access need.
This advice applies to pending applications. A rejected request is a different situation; Google’s standard documentation says applicants should verify that they meet the requirements before reapplying after a rejection.
Business Profile API access is gated by design
The backlog matters because the Business Profile APIs do not work like many ordinary Google developer services.
Google’s official overview says the APIs are intended for developers and platforms that need to manage Business Profile account and location data, including multi-location operations and customer-facing integrations.
But access is restricted. Applicants must demonstrate a legitimate business reason and meet Google’s eligibility requirements before the relevant Cloud project receives API access.
Creating a Google Cloud project and finding the API in documentation is not enough.
Applicants must meet specific prerequisites
Google’s current prerequisites require applicants to manage a Google Business Profile that has been verified and active for at least 60 days.
The profile can represent the applicant’s own office or headquarters or belong to a client the applicant manages. The business must also have a website representing the entity listed on the profile.
Google recommends keeping the Business Profile complete and current before submitting an application.
The applicant must create or select the Google Cloud project that will use the APIs and provide that project number in the access request.
The application email must be connected to the Business Profile
Google also instructs applicants to use an email address that is listed as an owner or manager of the relevant Business Profile.
This requirement is easy to overlook when development and local-search operations are handled by different teams.
A developer may control the Cloud project while a marketing or operations account controls the Business Profile. If the application is submitted without the expected relationship between those identities, the review process can become more complicated.
With the current backlog, avoiding preventable application errors is especially important because a rejected request can mean returning to an already congested queue.
Approval is granted to the Cloud project
Google Business Profile API approval is project-level access.
If Google approves the application, the selected Google Cloud project receives the relevant permission and standard quota. Users with appropriate access to that project can then build against the Business Profile APIs, subject to OAuth, Business Profile permissions and Google’s policies.
This is another reason not to submit multiple applications casually. The project selected during the application process is part of the access architecture, not merely an administrative field.
Teams should confirm that they are applying with the project intended for the production integration.
You can check approval through the API quota
Google documents a practical way to see whether a project has been approved.
In Google Cloud Console, a Business Profile API quota of zero queries per minute means the project has not yet been granted access. A standard quota of 300 queries per minute indicates approval.
This can help developers distinguish “still not approved” from uncertainty about whether an email was missed.
It does not reveal where the application sits in Google’s review queue or how long the remaining wait will be.
The backlog is not an API outage
The distinction between access approval and API availability is important.
Google’s notice concerns applications from developers seeking permission to use the Business Profile APIs. It does not say that existing approved integrations have stopped working.
An agency already operating an approved project should not infer from the backlog that API requests are generally failing.
Likewise, a pending access application is not the same problem as hitting an API quota after approval.
These issues occur at different stages of the lifecycle and require different responses.
Application delays and quota limits are separate
Once a project is approved, Google applies standard API usage limits.
The company’s quota documentation lists standard limits such as 300 queries per minute for several Business Profile APIs, with additional endpoint-specific limits.
Quota exhaustion can generate rate-limit errors and may require request pacing or a quota-increase process.
None of that solves a pending basic-access application.
Google explicitly notes that a project showing a zero quota has not yet been granted access and should use the basic API access process rather than request a quota increase.
The delay can block local SEO platforms before development even begins
For a software company building a Business Profile integration, access approval sits before much of the production work.
The APIs can support location management, profile updates, reviews, posts, media, verifications, notifications and performance-related workflows. Without an approved project, developers cannot simply proceed as though the production API were open.
A backlog therefore affects product timelines differently from a temporary runtime incident.
An outage may interrupt an integration that already exists. An approval delay can prevent the integration from reaching production in the first place.
Multi-location agencies have particular exposure
The APIs are especially useful for organizations managing large numbers of business locations.
Manually updating hours, attributes, posts or other profile data through the interface can be workable for a handful of listings. It becomes operationally expensive at hundreds or thousands of locations.
Agencies and SaaS platforms use programmatic access to centralize those workflows and synchronize business data across systems.
If a new provider cannot obtain API approval on its expected timeline, onboarding large clients can become more difficult even if the rest of its platform is technically ready.
The APIs require OAuth after project approval
Approval is not the final implementation step.
Google Business Profile APIs use OAuth 2.0 for requests involving protected account and location data. The business owner or authorized user must grant the application permission to operate on the relevant Business Profile.
Google’s OAuth documentation explains that this consent establishes both the identity of the business owner and the identity of the partner platform.
This architecture means API approval does not give a developer universal access to Business Profile data. The project can call the APIs, but it still needs authorized access to the individual accounts and locations it manages.
Approved API access does not unlock every Google Business Profile
This distinction is central to the security model.
Google’s FAQ states that receiving Business Profile API access does not allow a developer to query arbitrary business profiles.
The developer must have permission for the particular Business Profile involved.
That prevents the approval process from becoming a general-purpose database-access mechanism for Google Maps listings.
For platform builders, it means the product architecture must include both Google Cloud project approval and user-level authorization.
Teams should avoid changing projects mid-process without a reason
Because approval is tied to the Cloud project, development teams should document exactly which project number was submitted.
Creating a new project while the first application is pending does not automatically accelerate access and can introduce confusion about which environment Google is reviewing.
The current advice against duplicate applications reinforces the need for disciplined project ownership.
If organizational requirements genuinely change, teams should follow Google’s support guidance rather than attempting to create multiple competing requests as a workaround.
There is no public queue position to monitor
Google has not exposed a dashboard showing application position, expected review date or queue length.
The available signals are comparatively simple: the application has been submitted, Google eventually sends a follow-up after review, and the project quota can indicate whether access has been approved.
That lack of intermediate status is more frustrating during a backlog because developers cannot tell whether a request is days or weeks away from resolution.
For project managers, the safest assumption is that approval timing is currently uncertain rather than trying to infer a date from the age of another applicant’s request.
Do not interpret individual wait times as a universal benchmark
As developers begin sharing their experiences, some will inevitably report unusually fast or slow approvals.
Those anecdotes can confirm that a backlog is affecting real applicants, but they cannot establish the current average review time.
Applications can differ in business model, profile history, documentation quality, project setup and the complexity of Google’s review.
Without a published distribution from Google, there is no defensible universal statement such as “approval now takes 30 days.”
The only authoritative current timing statement is that processing is taking longer and Google cannot provide an ETA for pending requests.
The backlog increases the cost of incomplete applications
When normal review times are predictable, correcting a rejected application is inconvenient. During a backlog, it can become a launch risk.
Applicants should therefore verify the prerequisites before submission: an active verified profile of sufficient age, a valid business website, the correct Cloud project, a legitimate business use and an applicant email with the appropriate Business Profile role.
None of those steps guarantees approval, but they reduce the chance that a preventable eligibility problem forces the team to start another review cycle.
Google’s advice to keep the profile complete and current is particularly relevant here.
Local SEO teams should separate API dependency from launch dependency
Organizations building new local-search workflows should identify which product features truly require the Business Profile APIs and which can be developed or tested independently while access is pending.
Data models, OAuth interface design, internal workflow logic, mock responses and other parts of the integration may be prepared before production access arrives.
Google’s documentation notes that there is no general production sandbox for the Business Profile APIs, although mock responses can be used for testing and some requests support validation behavior.
Planning around that constraint can prevent the approval queue from stopping every part of development.
The uncertainty matters more than the delay itself
API access reviews have always introduced some lead time. What changes the planning equation now is the absence of a reliable timeframe.
A company launching a multi-location product can tolerate a known two-week review by submitting early. It is much harder to commit to a customer date when the platform owner says the request volume is unusually high and cannot estimate when pending applications will be processed.
That uncertainty should be communicated to customers and internal stakeholders as a third-party dependency rather than hidden inside the engineering schedule.
It also argues for requesting access well before the date when production integration becomes business-critical.
Google’s current message is to wait, not resubmit
For developers already in the queue, there is no technical optimization that accelerates the review.
Google has acknowledged the unusually high application volume, warned that processing times are longer and said it cannot provide an estimated timeframe for pending requests. Its explicit recommendation is not to send additional applications while the current one remains in progress.
The backlog does not mean the Business Profile APIs are down, nor does it mean approvals have stopped. Existing integrations are not reported as affected by this notice, and Google has not published a new universal wait-time benchmark.
For agencies and platform developers, the practical response is to verify that the original application meets the documented requirements, monitor the project’s approval status and avoid duplicate submissions.
Until Google clears the queue or publishes a new timeline, Business Profile API access needs to be treated as an unpredictable external dependency—one that can delay a local-search product before its first production API call is ever made.