Ce guide est disponible en anglais.
What Is a Business Listings API?
A business listings API manages a business's name, address, hours and more across many publishers at once, with sync status and duplicate detection built in.
En bref
- Ce que ce guide permet
- Explain what a business listings API is, what it manages, and how it differs from calling each publisher's API yourself.
- API utilisées
- post
/api/v1/locationsCréer un établissement - patch
/api/v1/locations/{id}Mettre à jour un établissement - get
/api/v1/listingsObtenir la fiche d'un établissement - get
/api/v1/connectionsLister les comptes connectés
- post
- Référence
- LocationsFiches publiéesConnexions
- Prérequis
- None. This is a concept page; the guides linked from it have the code.
- Cas d'usage typiques
- Deciding whether you need a listings API at all
- Explaining the category to a product or engineering lead
- Scoping an integration before you start
A business's core facts are simple: name, address, phone, hours, categories, photos. Keeping them identical across Google, Apple, Bing, Facebook, and the long tail of directories is not. Each publisher has its own data model, its own approval process, and its own idea of when a change goes live. A business listings API does that fan-out for you. You edit the location once, and it translates and pushes the change to every publisher.
One location, many publishers
The core object is a location. Create one with POST /api/v1/locations, change it with PATCH /api/v1/locations/{id}. The API owns the rest: reshaping that single record into each publisher's format and delivering it. The features that exist only because there are many publishers come with it.
- Per-publisher sync status, so you can tell whether a change actually landed on each directory (
GET /api/v1/listings), not just whether your write was accepted. - Duplicate detection, because the same business often ends up listed twice on one directory, and catching that needs a view across publishers.
- Aggregated reviews, since reviews arrive on many platforms and an owner wants a single inbox.
- Connections, the consent and credentials that let the API write to a publisher on the business's behalf (
GET /api/v1/connections).
A queue, not a database you own
Internalise this: you do not hold the data, you queue changes into it. Publishing is asynchronous and partly outside anyone's control. Google reviews some edits before they show. Directories refresh on their own clocks. That is why sync status is a first-class feature and not an afterthought. A write that returns 200 means the change was accepted and queued. It does not mean it is live on Maps.
It is also not the same as one publisher's own API. Google's Business Profile API manages Google in full and nothing else. A listings API manages presence across publishers and adds the cross-publisher features. Which one fits comes down to how many publishers you care about, and that trade-off has its own page: Google Business Profile API vs a listings management API.
The real reason to buy instead of build
It is maintenance. Building straight against each publisher means several OAuth apps, several data models, several review processes, and several deprecation schedules to track, forever. A listings API collapses that into one REST API with one version to follow. You trade some direct control for not owning that surface. When the trade is worth it, and when it is not, is the subject of the direct-versus-Synup comparison.
Ready to build? The Business Listings API guide runs the whole loop, from creating a location to confirming it is live on every publisher. For the delivery mechanics underneath, read how listing syndication works. For the day-two job of keeping listings correct, see managing business listings.