Esta guía está disponible en inglés.
Google Business Profile API vs a Listings Management API
How Google's Business Profile API compares with a listings management API on scope, access, sync status, duplicates and reviews, and when to use each.
De un vistazo
- Qué logra esta guía
- Explain what each API covers, what each one costs to adopt and run, and give a rule for choosing between them or combining them.
- APIs utilizadas
- get
/api/v1/connections/google/connect-urlObtener una URL de conexión de Google - patch
/api/v1/locations/{id}Actualizar una ubicación - get
/api/v1/listingsObtener el listado de una ubicación - get
/api/v1/listings/duplicates/rollupObtener el resumen de listados duplicados - get
/api/v1/reviewsListar reseñas
- get
- Referencia
- ConnectionsListados publicadosLocations
- Requisitos previos
- None. This is a concept page; the guides linked from it have the code.
- Casos de uso habituales
- Deciding how to add Google Business Profile management to a product
- Estimating the integration work for multi-publisher listings
- Explaining the trade-off to a product or engineering lead
The Google Business Profile API manages one publisher, Google, and does it in full: locations, attributes, photos, posts, reviews, insights, for accounts that have granted your app access. A listings management API manages the business's presence across many publishers at once, Google included, and adds the parts that only exist across publishers: sync status per directory, duplicate detection, and reviews aggregated from more than one platform. The choice is about scope and maintenance, not capability on Google itself.
What each one covers
| Google Business Profile API | Listings management API (Synup) | |
|---|---|---|
| Publishers | Google only | Google, Apple, Bing, Facebook and the directory network |
| Getting access | Apply for API access from Google, build an OAuth app, pass its review, work within per-project quotas | Create an API key in Synup; the business owner consents to Google once through a connect URL |
| Data model | Google's: accounts, locations, attributes, PlaceInfo, BusinessHours types | One location record with a shared shape; Synup maps it to each publisher's format |
| Updating a profile | Call Google's location endpoints per field group | PATCH /api/v1/locations/{id} once; the change is queued to every connected publisher |
| Sync status | Google's own verification and update state | Per-publisher status for every directory (GET /api/v1/listings) |
| Duplicates | Not detected; you find them yourself | Detected, scored and resolvable (GET /api/v1/listings/duplicates/rollup) |
| Reviews | Google reviews, with reply | Google, Facebook and custom review pages, with reply where the platform allows (GET /api/v1/reviews) |
| Analytics | Google performance metrics | Google, Facebook, Apple and Bing metrics side by side, plus rank tracking and AI visibility |
| Token lifecycle | Yours: refresh, expiry, re-consent | Synup's: it reports credentials_invalidated and you re-issue a connect URL |
| Maintenance | Track Google API deprecations and versions | Track one REST API with a version prefix |
What is the same either way
The business owner has to consent. Google's profile is the owner's, and no API reaches it without an OAuth grant
from their account. With Google's API that grant goes to your app. With Synup it goes to Synup, kicked off by
the URL from GET /api/v1/connections/google/connect-url. Either way it's an interactive screen a person completes, and
neither can be automated away.
Publishing is asynchronous either way too. Google reviews some changes before they show, and a listings API faces that same delay on Google and on every other directory, which is exactly why a pollable sync status matters more, not less.
When to use the Google Business Profile API directly
- Google is the only publisher you'll ever need, and you know that with confidence.
- You need a Google feature the day it ships, ahead of any intermediary.
- You already run an approved Google API project and the token lifecycle it implies.
- The product is a Google specialist tool and its users expect Google's own vocabulary.
When to use a listings management API
- The business needs to be correct on Apple, Bing and the directories as well, which is the common case for anyone whose customers use maps, voice assistants or AI answers.
- You want sync status and duplicate management as features rather than as internal tooling.
- You don't want to apply for Google API access, build and maintain an OAuth app, or own token refresh.
- Reviews from more than one platform should live in one inbox.
- Being live this quarter matters more to you than owning the Google integration for the next five years.
Using both
Some teams keep a direct Google integration for one Google-only feature and use a listings API for everything else. That works if you keep one boundary. Let the listings API own the profile fields it manages, and don't write those same fields through Google directly, or the two overwrite each other on the next sync. Reading from both is always fine.
How Synup relates to Google's API
Synup's Google connection is itself built on Google's Business Profile API, under Synup's approved project.
When a location's profile changes through PATCH /api/v1/locations/{id}, Synup translates the shared location
shape into Google's and submits it. When a review arrives on Google, Synup fetches it. The
Google Business Profile guide covers the connection, listing matching
and reconnects in detail.
If a listings management API is the right shape for you, the complete developer guide walks the whole loop, from creating a location to confirming it's live on every publisher.