Listings integrations for platforms
Keeping a business accurate across Google, Apple, Bing, and Facebook means writing the same record into four very different systems and keeping them in sync. Here are the patterns that hold up, where each publisher gets in the way, and how Synup runs the whole thing behind one key.
// Write a location once. It syncs to the network.
const headers = {
'Authorization': 'API your_api_key',
'Content-Type': 'application/json'
};
const res = await fetch(
'https://api.synup.com/api/v4/locations',
{ method: 'POST', headers, body: JSON.stringify({
name: 'Bloom Coffee', address: '12 Main St',
city: 'Austin', state: 'TX', country: 'US'
}) }
);
const { data } = await res.json();
// Then subscribe to the listing.submission webhook
// for per-publisher status as it propagates.What a listings integration has to do
On the surface the task sounds small: keep a business's name, address, phone, hours, and categories correct everywhere customers find it. In practice you're writing one record into several systems that disagree on field names, verification rules, and how long a change takes to go live. The integration is less about the first write and more about keeping everything in agreement after it.
Each destination is its own world. One needs OAuth and an approval process before you can touch a location. Another only lets you manage places you've verified. A third publishes in minutes when the data auto-verifies and stalls for days when it doesn't. Build for one and you've learned almost nothing transferable about the next.
So a real integration is three problems, not one: model a clean source record, push it to each publisher in the shape that publisher wants, and reconcile what actually went live against what you sent. The sections below walk through the pattern that keeps those three honest, then where each major publisher makes it harder.
One source of truth, synced outward
The pattern that survives contact with production is a single canonical record per location that you own, with every publisher treated as a downstream copy. You never edit a publisher directly as the system of record. You change the canonical location, and a sync layer pushes that change out and records what each destination did with it.
Make the writes idempotent. Each push should carry your own stable location id so a retry updates the same place instead of creating a duplicate, which is the most common way listing data goes wrong at scale. Keep a small per-publisher state record next to the canonical one: the last payload you sent, the last status you got back, and a timestamp. That state is what lets you tell "not synced yet" apart from "synced and then drifted."
Then close the loop. Publishing is rarely instant or guaranteed, so the system has to reconcile: read back what went live, compare it to the canonical record, and re-push the difference. Whether you build that loop yourself or let a platform run it, the shape is the same, and getting it right matters more than any single endpoint.
Every publisher is its own integration
A snapshot of the major destinations and how access works on each, current as of mid-2026. All of this shifts, so treat each publisher's own docs as the source of truth before you build.
Google Business Profile
OAuth 2.0, access-application gated
The Business Profile APIs are a federated set, not one endpoint, and access isn't open by default. A new Google Cloud project starts with zero quota and you submit a formal request before calls work. Writes are scoped to locations the authenticated account manages.
The full GBP API playbookApple Business
Partner application, OAuth
Apple folded Business Connect into the unified Apple Business platform in 2026. The Business API is partner-access by application, aimed at managing locations at scale. When data auto-verifies, a submission can publish in around 15 minutes; when it doesn't, it waits on review.
Apple BusinessBing Places
Verified-owner / partner scoped
Bing Places has a real listing API that reads, creates, and updates locations, with bulk operations for chains. It only exposes places tied to your verified account, and it can import from an existing Google profile to speed setup. It feeds Bing, and increasingly Copilot.
Bing Places for BusinessFacebook (Meta)
OAuth 2.0 + App Review
Facebook Pages are managed through the Graph API. A user consents, you exchange that for a Page access token, and production access to Pages you don't own needs App Review plus Business Verification. Tokens refresh on a roughly 60-day cycle, so token handling is ongoing work.
Meta Pages APIDesigning for partial failure and drift
Once you're writing to four publishers, the interesting failures stop being a single bad request and start being partial. A change lands on two networks, sits in review on a third, and bounces on the fourth because a category isn't allowed there. A design that assumes one success or one failure per change won't model what actually happens.
Treat every submission as asynchronous. You send a change, you get an acknowledgement, and the real outcome arrives later through a status you poll or a notification the publisher sends. Store status per location per publisher, not one global flag, so a location can be live on Google, pending on Apple, and errored on Facebook at the same moment and your dashboard tells the truth.
Drift is the slow version of the same problem. A publisher edits a field from its own side, a third party suggests a change, or a verification lapses, and your copy quietly stops matching reality. The reconcile loop from earlier is what catches it: read back, compare, re-push. Build it once and treat new publishers as new adapters into the same loop rather than new special cases.
One key, one record, the network behind it
Synup runs that whole pattern as a service. Auth is one header, Authorization: API your_api_key with Content-Type: application/json. There's no per-publisher OAuth dance for you to run, no app review to pass, and no token refresh to babysit, because the publisher relationships sit on Synup's side.
You write a location once against /api/v4/locations, and it becomes the canonical record that propagates to the directory network. Status comes back through the listing.submission webhook, which you enable through support with your endpoint set in Settings, so you get the per-publisher updates without polling each one. The general rate limit is 75 requests per minute and can be raised for a heavier workload.
The reconcile loop, the per-publisher state, the async status, all of it still exists. It just runs inside the platform instead of inside your codebase, and it returns one normalized shape rather than four different ones. That's the difference between operating an integration and operating four.
Build the adapters, or rent the network
Building direct makes sense when listings are your core product and you want to own every adapter, every token, and every approval. You get full control and you carry the full maintenance: each publisher's access process, its auth model, and its changes over time, repeated for every network you add.
Renting makes sense when accurate presence is a feature of your product rather than the product itself. Synup already holds the relationships and runs the sync, so you integrate once and reach the network, with reviews, rank, and analytics available through the same key. The patterns on this page still apply either way, they just decide what you operate yourself.
Listings Integrations FAQs
Common questions on per-publisher integration, auth, async status, duplicates, and rate limits. The developer docs cover every endpoint in full.
Do I need a separate integration for each publisher?
If you build direct, yes. Google, Apple, Bing, and Facebook each have their own access model, auth, and field shape, so each is its own adapter to build and maintain. Synup exposes them behind one key and one schema, so you integrate once.
How does Synup authenticate, OAuth or an API key?
An API key. Send it as Authorization: API your_api_key with Content-Type: application/json. OAuth only enters the picture when you connect a Google or Facebook profile to an account, not for calling the API itself. How to find and generate your key
How do I know when a listing actually goes live?
Submission is asynchronous, so you watch status rather than assume success. Synup sends per-publisher updates through the listing.submission webhook, which you enable through support with your endpoint configured in Settings.
How do I avoid creating duplicate listings?
Make writes idempotent by carrying your own stable location id, so a retry updates the same record instead of creating a new one. Keep per-publisher state next to the canonical record so you can tell a pending sync apart from a drifted one.
What are the rate limits?
The general limit is 75 requests per minute, and it can be raised for a specific use case. API access is included in all Synup plans, so there's no separate metering on listing calls.
Integrate once, reach the network
Get a Synup API key and sync locations across Google, Apple, Bing, and Facebook behind one schema. We'll provision a sandbox so you can test against live data before any sales call.