Listings Management

One create call queues the location for submission across your plan's full network of citations. The business data is submitted to all publisher sites that are included in your plan. Refer to https://www.listingsapi.com/network.

Call GET /api/v4/locations/{id}/listings/premium, which returns one record per citation with a syncStatus enum. When a record reads SYNCED it is live, and its listingUrl gives you the public link to that citation.

Read the syncIssue field on the failing record for the reason, alongside syncStatus for the accurate state of that citation. A REQUIRING_ACTION status means the citation is waiting on a manual step, most often a disconnected account or an unverified profile. Inspect the action required and update the business data accordingly.

Both. Connect a Google or Facebook account, then call POST /api/v4/connected-accounts/connected-account-listings to page through the listings that account already owns. Call POST /api/v4/connected-accounts/create-location-from-listing to import an existing location from the connected accounts, or POST /api/v4/connected-accounts/connect-listing to attach it to a location you already have.

Yes. Every object is readable through the same REST API you write with. Page through GET /api/v4/locations or searchLocations using pageInfo.endCursor until hasNextPage is false to pull every location, then listingsForLocationPremium for the per citation record, plus the reviews, posts, and analytics endpoints for the rest.

Listings management is keeping a business's name, address, phone, hours, categories, description and photos accurate on every site that publishes them. Done by hand it means signing into dozens of dashboards and making the same edit in each, then doing it again the next time something changes. Every step of it is an API call here. POST /api/v4/locations creates the business and queues it across the citations on your plan. POST /api/v4/locations/update sends only the fields that changed and re-syncs every citation from the same values. GET /api/v4/locations/{id}/listings/premium returns one record per citation with its own syncStatus, a human-readable displayStatus and the live listingUrl once there is one, so verification is a response rather than a manual check. The part worth doing programmatically is not the first publish, it is everything after it. A citation is only useful while it is still accurate, and this is what makes staying accurate one call instead of a standing chore.

A local citation is any listing of a business's core details on a third-party site: the name, address, and phone number, plus hours, categories, and website. Search engines read those citations as corroboration, so when they disagree the business is harder to place and looks less trustworthy. Building them by hand means submitting the same record to each directory, then resubmitting it every time something changes. Programmatically it is one write. POST /api/v4/locations creates the canonical record and queues it across every citation on your plan, and a later update re-syncs all of them. Because each citation reports its own syncStatus, you read back which ones are live instead of spot-checking directories, which is the part manual citation building never gives you. The publisher list by plan is on the network page.

Business listing management is the ongoing job of keeping one business's details correct everywhere they are published, not the one-time act of getting listed. It matters because local search resolves a business from many sources at once. The failure mode is drift: you change a phone number in one profile, forget the dozen directories that also carry it, and now the web disagrees with itself. Conflicting name, address, and phone data costs a business the corroboration that ranks it, and sends real customers to a number nobody answers. The programmatic version removes the drift by removing the copies. One record is canonical, every citation is published from it, and a single update re-publishes them all. Reading per-citation status back through the API turns "we think it is fixed" into something you can assert.

Local listing management software keeps business data accurate across directories, maps, and social profiles from one place. Five things decide whether one is any good: whether there is real API access or only a UI, how many publishers it reaches and on which plan, whether it reports per-publisher sync status rather than just claiming success, whether the pricing is published, and whether you can ship it under your own brand. Be honest about which kind you need. A team managing its own handful of locations wants a dashboard, and a dashboard is a reasonable thing to buy. A team building listings management into a product for other people needs the layer underneath one: endpoints, typed SDKs, and status it can render in its own interface. Listings API is the second thing. There is a playground, but the product is the API, which is the distinction drawn on compare.

Citation building is the one-time act of submitting a business to a directory. Citation management is keeping that submission correct afterwards. The distinction matters because only the second one is worth automating: submitting once is easy at any scale, but a citation only has value while it is still accurate. POST /api/v4/locations automates the building, queueing the business across every citation on your plan with no per-directory form to fill in. The ongoing half is where the automation actually pays. POST /api/v4/locations/update takes only the fields that changed and re-syncs every citation, and each one reports its own syncStatus so you can see what landed. Publishers differ in how quickly that happens: some accept the write in real time, others run their own verification first. That is why status is a read rather than an assumption.

Citation cleanup is fixing business data that is already wrong and already scattered: stale phone numbers, old addresses, and duplicate records competing with each other. As an API workflow it is four steps. Detect with GET /api/v4/locations/listings/duplicates, an account-wide paginated rollup of potential duplicates across every location. Dedupe with POST /api/v4/locations/listings/mark-as-duplicate, which takes an array of listingItemIds, and mark-as-not-duplicate to clear false positives the same way. Overwrite with POST /api/v4/locations/update, which rewrites the canonical record and re-syncs every citation from it. Verify with the premium listings read, which returns per-citation syncStatus and the live link. Two of those four are genuinely bulk: the duplicate rollup and both mark calls accept arrays. Location updates are one call per location, so cleaning a large portfolio is a loop, paced to your plan's rate limit.

NAP consistency means the name, address, and phone number are identical everywhere the business appears. It is a data-integrity problem rather than a content problem: there is no copy to write and no keyword to place, only one fact that has to be the same in every copy of it. Enforcement by discipline does not hold, because any process that depends on remembering to update a dozen directories eventually will not. The structural fix is to stop keeping copies. The location record is the single source of truth and every citation is published from it, so changing the record is the only way the published data changes. Send the edit once to POST /api/v4/locations/update and every citation on the plan re-syncs from the same values. Divergence then becomes something you detect in a read instead of something you hope has not happened.

Listings API detects duplicates and gives you four endpoints to resolve them. GET /api/v4/locations/{locationId}/listings/duplicates returns the duplicates found for one location, grouped by publisher site, each carrying a listingItemId and a live link. GET /api/v4/locations/listings/duplicates is the account-wide version, paginated and filterable by status so you can pull everything still marked POTENTIAL. Once a reviewer has judged them, POST /api/v4/locations/listings/mark-as-duplicate takes an array of listingItemIds and submits them for suppression, and POST /api/v4/locations/listings/mark-as-not-duplicate dismisses false positives so they stop reappearing in the list. It is worth being precise about the word merge: these calls confirm which record is the duplicate and keep your canonical listing authoritative. Both accept multiple IDs, so batch a confirmed group into one request rather than calling per listing.

Directory submission is a one-time event: the business details are sent to a directory and the process ends. Listings management is continuous: the details are published, kept in sync as they change, and reported on per publisher. The gap between them is verification. A submission tells you a form was accepted, which is not the same as a listing being live, correct, and still correct next quarter. Listings API is built as the second kind. One create call queues the business across the citations on your plan, one update re-syncs all of them, and GET /api/v4/locations/{id}/listings/premium returns one record per citation with its own syncStatus, a human-readable displayStatus, and the live listingUrl once it exists. A REQUIRING_ACTION status names a citation waiting on a manual step, which is exactly the state a submit-and-forget process cannot report.