Ce guide est disponible en anglais.

How to Update Business Information Across Google, Apple, Bing and Directories

Push one business-information change to Google, Apple, Bing and the directory network through a single API call, and verify it reached each publisher.

One PATCH, many directories. That is the point of doing this through a listings API instead of logging into Google, then Apple, then Bing: you change the location record once and the change fans out to every connected publisher. The work that is left is knowing what reaches where, and confirming it actually arrived.

The one call that reaches everywhere

PATCH /api/v1/locations/{id} takes any subset of the profile and queues the change to every connected publisher. A field you send replaces its current value. A field you leave out is untouched. You do not address publishers individually. You write the location, and syndication handles Google, Apple, Bing and the rest.

curl -X PATCH https://ai.synup.com/api/v1/locations/LOCATION_ID \
  -H "Authorization: Bearer $SYNUP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "phone": "+1 415 555 0199",
    "website": "https://grovestreetdental.example/mission"
  }'

The mechanics of building a safe update (read first, send only the diff, empty means clear) are the subject of the managing listings guide. This page is about the part that is specific to going across publishers.

What reaches which publisher

Not every field exists on every publisher, and that is not a failure, it is the nature of the network. A shared field like name, address, phone, website and hours maps to all of them. A Google-specific attribute has nowhere to go on a directory that has no concept of it, so it is simply not sent there. Two consequences for how you build:

• Categories are per publisher. Each publisher keeps its own category tree. Send categoryName for the general match, and pass publisherCategories as an { id, name } per publisher, resolved from GET /api/v1/locations/publisher-categories, when you want the exact category on a specific publisher.
• Connections decide reach. A change only reaches a publisher the location is connected to. GET /api/v1/connections tells you which publishers a location is actually wired to, so you know the real spread of any update before you send it.

Publishing is not instant, and the delay is the publisher's

The write returns as soon as Synup has stored and queued the change. Getting it live is asynchronous and varies by publisher: directories can take minutes, and any publisher that reviews edits by hand takes longer. Google in particular reviews some fields before they show. None of that delay belongs to the API; it belongs to the publisher. Build for "queued, then live", never "saved equals live". The full mechanics are in how listing syndication works.

Confirm it reached each publisher

This is the step people skip and regret. GET /api/v1/listings returns the per-publisher status for one location, so you can show a business owner a row per directory: synced, pending, or a problem.

curl "https://ai.synup.com/api/v1/listings?locationId=LOCATION_ID" \
  -H "Authorization: Bearer $SYNUP_API_KEY"

After a change across many locations, do not loop that call. GET /api/v1/listings/summary answers for the whole set at once: a per-location table of synced-against-total publisher counts, plus a ranked list of what needs attention, so you can find the locations where an update stalled instead of polling each one.

Next

Once information is consistent everywhere, the next thing that erodes it is duplicates on those same publishers. Find and remove duplicate listings is the cleanup. For the field-by-field update mechanics, stay with the managing listings guide, and the quick tasks have their own recipes: update opening hours and upload business photos.