Ce guide est disponible en anglais.
Building Publisher Integrations Directly vs Using Synup
What it really costs to integrate Google, Apple, Bing and directories yourself, versus one API, and how to decide between them or combine both.
En bref
- Ce que ce guide permet
- Compare building direct publisher integrations against using one listings API, on cost, control and maintenance.
- API utilisées
- patch
/api/v1/locations/{id}Mettre à jour un établissement - get
/api/v1/listingsObtenir la fiche d'un établissement
- patch
- Référence
- Fiches publiéesConnexions
- Prérequis
- None. This is a concept page; the guides linked from it have the code.
- Cas d'usage typiques
- Making a build-versus-buy call for listings
- Estimating the real cost of direct integrations
- Explaining the trade-off to an engineering lead
You can build against each publisher yourself. Google, Apple and Bing all have APIs or feeds, and for a single publisher that is a reasonable project. The question is what happens when you need several, and what it costs to keep them running for years, not what it costs to get the first write to succeed.
What "direct" actually means for each publisher
Building direct is not one integration, it is several, and they do not resemble each other:
- Google means applying for Business Profile API access, building and passing review on an OAuth app, and owning token refresh, quotas and version changes.
- Apple means Apple Business Connect and its own onboarding and format.
- Bing means its places feed and its own rules.
- The directory network is dozens of smaller publishers, many without a clean API at all, each with its own update path and its own idea of a category.
Each one has a different data model, a different auth story, and a different release cadence you now have to follow. The cost is not the first integration. It is carrying all of them, forever, as each one changes.
The trade in one table
| Build direct | One listings API | |
|---|---|---|
| First publisher | Reasonable | Reasonable |
| Fifth publisher | Another full integration | Already included |
| Auth to maintain | One app per publisher | One API key |
| Data models | One per publisher | One shared shape |
| Sync status | You build it | A read (GET /api/v1/listings) |
| Duplicates | You detect them | Detected and resolvable |
| When a publisher changes | Your problem | Absorbed behind the API |
| Direct control | Full | Bounded by what the API exposes |
When building direct is the right call
- You will only ever need one publisher, and you are sure of that.
- You need a publisher feature the day it ships and cannot wait for an intermediary.
- The integration is your product's core differentiator, not plumbing under it.
When a listings API wins
- You need to be correct on several publishers, which is most real local-marketing products.
- You would rather ship features than maintain OAuth apps and category maps.
- You want sync status and duplicate handling without building them.
You can also draw a line and use both
Some teams keep one direct integration for a single publisher-specific feature and use a listings API for
everything else. That works as long as you keep a clean boundary: let the listings API own the fields it manages
through PATCH /api/v1/locations/{id}, and do not write those same fields directly to that publisher too, or the
two overwrite each other on the next sync. Reading from both is always fine. The
GBP-versus-listings page works the same trade
for the specific case of Google, and the listings API concept explains
what the managed layer covers.