Google's planned 2027 expansion of Local Services Ads (LSAs) creates an important technical question for agencies and software providers: will Google Ads API capabilities expand at the same pace as the advertiser migration?
Google's migration roadmap says non-US accounts and remaining business categories will transition to Performance Max campaigns with pay-per-lead goals in 2027. Yet the current Google Ads API documentation still restricts the country_code field for these campaigns to US.
This is not proof that international API support will arrive late. Google may update its API documentation and regional capabilities before the relevant migration phases begin. But it exposes an integration risk that agencies should address before international accounts move into the new campaign architecture.
The issue is bigger than campaign creation. It affects account provisioning, location validation, campaign automation, conversion-goal configuration, reporting, and the ability to manage multiple markets through a single software layer.
The migration roadmap and API documentation are not at the same stage
Google is moving LSAs into a specialized Performance Max campaign structure while retaining the pay-per-lead model and local placements on Search and Maps.
Its published migration schedule has three broad phases:
| Migration phase | Expected rollout |
|---|---|
| Phase 1 | August 2026: selected US home and storefront services |
| Phase 2 | Late 2026: broader advertiser groups, including service-area businesses and professional services |
| Phase 3 | 2027: non-US accounts and remaining supported categories |
Source: Google's LSA migration roadmap.
The API documentation describes a more limited geographic capability at present. The Performance Max for pay-per-lead setup requires a two-letter country code in local_services_pmax_campaign_settings.country_code, and the documented supported value is US. The documentation also states that location criteria must belong to the campaign's home country.
That creates a distinction between two forms of availability:
- Product availability: An advertiser can use the pay-per-lead campaign experience in a particular market.
- API availability: A developer or agency can create, configure, and manage that campaign programmatically in that market.
These capabilities are related, but they are not interchangeable. A campaign becoming available in the Google Ads interface does not automatically establish that every API workflow, field, validation rule, or regional dependency is available too.
Sources: Google Ads API: Performance Max for pay-per-lead goals and supported business verticals.
The country code is a provisioning constraint, not a cosmetic field
Consider an agency managing campaigns for plumbing businesses in the United States, the United Kingdom, and Australia.
A conventional campaign-management platform might represent each account using a shared configuration:
{ "business_id": "client_104", "market": "GB", "country_code": "GB", "business_profile_id": "123456789", "campaign_type": "LOCAL_SERVICES_PMAX", "lead_goal": "PHONE_CALL_LEAD" } This is a simplified internal representation, not a Google API request.
The problem emerges when the provisioning service translates that configuration into Google's campaign resource. If the API validates the country code against the currently supported value of US, an international campaign cannot simply be created by substituting GB or AU.
The integration must distinguish between a market supported by the advertising product and one supported by the API provisioning workflow.
A robust system should therefore maintain a capability registry rather than assuming that every market supports every operation.
For example:
{ "market": "GB", "product_available": false, "api_campaign_creation": false, "api_campaign_updates": false, "location_targeting": "UNCONFIRMED", "last_verified": "2026-11-05" } The values above are illustrative. They should be populated from verified Google documentation and account-level eligibility checks, not treated as Google's published UK capability status.
This registry becomes particularly important during phased rollouts. Different accounts may become eligible at different times, even when they operate in the same country or vertical.
API version support does not eliminate regional restrictions
Google's API implementation has also evolved across versions.
The Local Services campaign documentation distinguishes standalone campaigns using:
advertising_channel_type = LOCAL_SERVICES from Local Services campaigns represented as specialized Performance Max campaigns:
advertising_channel_type = PERFORMANCE_MAX campaign.pmax_campaign_settings.local_services_enabled = true This distinction matters for integrations that identify campaigns by advertising channel type alone.
This is part of a broader API transition problem in Google's LSA migration. As I discussed in The Hidden API Problem in Google's LSA-to-PMax Migration, changes to campaign architecture can create compatibility challenges for agencies that depend on programmatic account management. The 2027 international expansion adds another dimension: regional API availability.
Google's documentation now describes Local Services Performance Max campaign creation and management through the API starting in version v26. Earlier API versions had more limited support, including update-only workflows for eligible campaigns created through the Google Ads interface.
However, API version support and geographic eligibility are separate constraints. Supporting the required resource fields in v26 does not mean every country can use them.
An integration can therefore pass its API-version checks and still fail during campaign creation because a required country, listing, location asset, or account prerequisite is unsupported.
Source: Google Ads API: Local Services campaigns.
Google Business Profile adds another dependency
Local Services Performance Max campaigns are not configured independently of business-location data.
The API workflow requires a Google Business Profile listing ID through local_services_pmax_campaign_settings.listing_id. Google validates this listing during campaign creation against the associated location assets.
This creates a dependency chain:
- The business has an eligible Google Business Profile.
- The listing is accessible through the connected Google Ads account.
- The required location assets are available.
- The campaign references the correct listing ID.
- The service-area targeting satisfies the campaign's geographic restrictions.
An international rollout may require more than accepting a new country code. It may also require market-specific validation rules, supported location criteria, phone-number formats, language constraints, and business-verification workflows.
For agencies, this means a campaign provisioning system should not treat a Google Business Profile listing ID as a globally interchangeable identifier. It must validate the relationship between the listing, the account, the market, and the campaign before submitting a mutation request.
Conversion goals create another layer of integration risk
Local Services Performance Max campaigns use a constrained set of lead conversion categories.
The current API documentation identifies:
PHONE_CALL_LEADMESSAGE_LEADBOOK_APPOINTMENTCONVERTED_LEAD, for eligible POS coupon partner campaigns
For non-coupon campaigns, phone-call leads are automatically configured as the required active goal. Message leads are created but disabled by default. Booking goals depend on an approved Reserve with Google partner being detected on the linked location.
These rules matter because an agency cannot safely assume that a campaign's conversion configuration is identical across every market or account.
A provisioning service should validate the goals returned by the API rather than assuming that a successful campaign creation request means every intended lead channel is active.
It should also separate campaign configuration from actual lead availability. A goal being technically configurable does not guarantee that the underlying service or partner integration is available in a particular market.
Source: Google's pay-per-lead API documentation.
What agencies should build before the 2027 rollout
The practical response is to make campaign automation capability-aware.
A single global provisioning workflow is attractive, but it can become fragile when product eligibility, API support, and verification requirements change independently.
A more resilient architecture should include five components:
1. Regional capability registry
Maintain a market-level record of supported campaign operations, API versions, verticals, conversion goals, and location requirements. Store the source and date of each capability check.
2. Preflight validation
Before creating a campaign, validate the account's market, business category, Google Business Profile listing, location assets, and required lead goals. Reject unsupported combinations before sending a mutation request.
3. Version-aware API adapter
Keep Google API resource mapping separate from internal campaign models. This makes it easier to handle changes to resource fields, validation rules, and API versions without rewriting the entire agency platform.
4. Idempotent provisioning
Use an internal provisioning state machine to prevent duplicate campaign creation when requests time out or return ambiguous errors. Record the Google resource name and mutation result before retrying.
5. Regional observability
Track API errors by country, API version, operation, campaign type, and error code. A rise in INVALID_LOCAL_SERVICES_PERFORMANCE_MAX_LISTING_ID errors, for example, should be investigated separately from country-code validation failures.
These controls also make it easier to identify whether a failure comes from account eligibility, API capability, location configuration, or a temporary service issue.
The real 2027 risk is assuming that product rollout equals API readiness
Google's 2027 LSA expansion is a significant platform change, but the most important engineering challenge may be hidden from advertisers. Agencies that depend on API-driven reporting, campaign provisioning, and multi-market automation need to prepare for regional capability differences.
The current documentation establishes a clear constraint: the documented pay-per-lead API workflow is US-specific, while Google's migration roadmap schedules non-US accounts for 2027. Whether those capabilities converge before international migration begins remains something agencies must monitor.
The safest approach is not to build international automation around an assumed rollout date. It is to build systems that can detect regional capabilities, validate account eligibility, and adapt when Google releases new API support.
A global advertising product needs more than a global migration announcement. It needs a globally consistent and documented integration surface.
