How Duplicate Listing Suppression Works
Duplicate suppression detects listings that look like the same business, scores them by confidence, and requests removal from the publisher that controls them.
At a glance
- What this guide accomplishes
- Explain how duplicates are detected, scored, flagged and removed, and where the API's control ends and the publisher's begins.
- APIs used
- get
/api/v1/listings/duplicates/rollupGet the duplicate-listings rollup - get
/api/v1/listings/duplicatesGet duplicate listings for a location - post
/api/v1/listings/duplicates/resolveResolve duplicate listings
- get
- Reference
- Duplicate ListingsListings Published
- Prerequisites
- None. This is a concept page; the guides linked from it have the code.
- Typical use cases
- Understanding what suppression actually does to a listing
- Setting expectations on how fast duplicates disappear
- Deciding an auto-flag policy
Suppression is a word that carries a warning. You are not deleting a row in a database you own. You are asking a publisher to remove a listing it controls, and it decides whether and when that happens. A duplicate is the second entry for one business on a publisher. It splits reviews, confuses maps, and drags ranking down. Getting rid of it is a request, not a delete.
Detection and scoring
Suppression starts with detection, which runs on its own. Synup scans each publisher for entries that resemble a business's own listing, comparing name, address and phone. For each candidate it records which fields match, a matchScore from 0 to 1, and a confidence band of high, medium or low. New candidates sit in a potential state until someone acts on them. You read that queue with GET /api/v1/listings/duplicates/rollup across a client, or GET /api/v1/listings/duplicates for one location.
Trust the score over the individual match flags. A duplicate that abbreviates the business name can score a confident match overall while its name-match flag reads false. Rank by the band and the score. Use the flags to explain a decision to a reviewer, not to make it.
Flagging is a request, not a deletion
When you decide a candidate is real, POST /api/v1/listings/duplicates/resolve with action: flag requests its removal. That does not delete anything by itself. It queues a request that a background job carries to the publisher, and the candidate moves through states as the publisher responds:
potential, waiting for a decisionflagged, removal requesteddeleted, the publisher removed itfailed, the publisher refused; you can flag it again
Dismissing a candidate (action: dismiss) marks it as not a duplicate and drops it from the queue.
The publisher owns the timeline
The removal itself is the publisher's action on the publisher's schedule. Some directories act quickly, some are slow, and some refuse, which is what a failed state records. So read suppression as a durable request with a status you poll, not a synchronous delete. The full duplicates guide covers reading the queue, choosing an auto-flag policy, and sweeping a publisher. The suppress recipe is the single call.