---
title: Choose Sync Mode and Matching
slug: choose-sync-mode-and-matching
type: how-to
plugin: huxx-connect-pro
summary: Pick the right Post Creator sync mode, adopt existing posts with Post Matching, and skip unchanged items — with the data-loss rules of Full sync spelled out.
keywords: [post creator, sync mode, full sync, post matching, match-by key, skip unchanged]
version_added: 1.3.5
version_updated: 1.3.5
level: intermediate
pro: true
related: [sync-api-data-to-posts, map-api-fields-to-posts, filter-hooks]
---

Every Post Creator (Pro) run answers two questions: *which existing post does this API item belong to?* (matching) and *what am I allowed to do — create, update, delete?* (sync mode). This page covers both, plus the skip-unchanged optimization.

> **Quick version:**
> 1. Configuration card → **Sync Mode**. Default is **Create & update** (`no_delete`) — keep it while testing.
> 2. **Full (create, update & delete)** (`full_sync`) deletes posts whose Unique Key is missing from the API response. Data loss is by design — read the warning below first.
> 3. Items match primarily by **Unique Key** (stored in post meta on every write).
> 4. To adopt posts that existed *before* Post Creator, use the **Post Matching** tab: compare an API field against Post Title, Post Slug, Post ID, or a custom meta field.
> 5. **Advanced → Skip items that have not changed** fingerprints items and skips untouched ones on later runs.

## The four sync modes

The **Sync Mode** select in the Configuration card offers four modes (stored values in parentheses):

| Mode (UI label) | Creates new posts | Updates matched posts | Deletes unmatched posts |
|---|---|---|---|
| Full (create, update & delete) (`full_sync`) | Yes | Yes | **Yes** |
| Create & update (`no_delete`) — default | Yes | Yes | No |
| Create only (`create_only`) | Yes | No | No |
| Update only (`update_only`) | No | Yes | No |

The 80% case is the default, **Create & update**: it mirrors the API without ever removing anything. **Create only** suits append-only feeds like event logs; **Update only** suits refreshing data on posts you create by other means.

## Full sync deletes posts — read this first

**Full (create, update & delete)** treats the API response as the complete source of truth. After each run, any post this configuration previously created whose Unique Key no longer appears in the response is **deleted — permanently**. Deletions bypass the trash entirely, so there is no recovery short of a database backup. Two situations make this dangerous:

- **A partial API response.** If the endpoint returns one page of results (DummyJSON's `/products` returns 30 of 194 by default), a full sync deletes everything outside that page. Configure endpoint pagination so the run sees the whole dataset before choosing this mode.
- **A too-narrow filter.** Results Filter rules apply before syncing — items your rules exclude count as "gone" and their posts are deleted.

When Full sync is selected, a **Protect matched posts from deletion** toggle appears (on by default): posts that were *matched* to existing content via Post Matching — rather than created by Post Creator — are kept even if they disappear from the API response. Turn it off only if adopted posts should follow the same delete rules as created ones.

## How items match posts: the Unique Key

On every write, Post Creator stamps the post with the item's Unique Key in hidden post meta. On the next run each item's key is looked up against those stamps — hit means update (or skip), miss means create (mode permitting). This is why the [tutorial](/docs/connect/tutorial/sync-api-data-to-posts/) insists on a key present in every item: items whose key is unresolved are skipped at runtime.

:::novice
A unique key is like a barcode: two products can share a name, but never a barcode. APIs almost always provide one — usually a field named `id`. See the [glossary](/docs/connect/explanation/glossary/) for the surrounding terms.
:::

## Adopt existing posts with Post Matching

If your site already has posts for the API's items — a manual catalog, an old import plugin's output — the first sync would create duplicates, because none of those posts carry a Unique Key stamp. The **Post Matching** tab solves this: when an item's Unique Key finds no stamped post, Post Creator falls back to comparing a field pair you configure.

1. Open the **Post Matching** tab and switch on **Match API items to existing posts**.
2. **API Source Field** — the item field to compare, e.g. `sku` (click into the field first, then click a leaf in the API Response tree to fill it — with no field focused, a leaf click copies the token to the clipboard instead).
3. **Match Against** — the WordPress side of the comparison:

| Match Against | Compares the API value to |
|---|---|
| Post Title | The post's title (exact match) |
| Post Slug | The post's slug |
| Post ID | The WordPress post ID (post must exist and be of the configured post type) |
| Custom Meta Field | A meta key you name, e.g. `legacy_product_id` |

When a match is found, the post is adopted: it gets the Unique Key stamp and is updated in place, and future runs match it by key directly. Matching only searches the configured post type, and the first matching post wins. Adopted posts are the ones **Protect matched posts from deletion** shields under Full sync.

## Skip unchanged items

Under Configuration → **Advanced**, the **Skip items that have not changed** toggle (off by default) makes repeat runs cheaper. Each sync stores a fingerprint of every item; on later runs, items whose fingerprint is unchanged are skipped instead of rewritten — faster runs, no needless post revisions. The fingerprint covers the entire raw item plus your mapping configuration. Two consequences: changing your field mappings re-syncs everything once, and a change to *any* field in the item — even one you haven't mapped — triggers a rewrite. If your API includes volatile fields (timestamps, view counters) that defeat the skip, use the [`item_hash`](/docs/connect/reference/filter-hooks/#huxx-connect-post-creator-item-hash) hook to fingerprint only the fields you care about.

Leave it off if other plugins or editors modify these posts and you want every sync to restore them from the API. Skipped items are listed in the Run Results panel under **Skipped**, so nothing disappears silently. Developers can override both decisions per item with the [`should_update`](/docs/connect/reference/filter-hooks/#huxx-connect-post-creator-should-update) and [`item_hash`](/docs/connect/reference/filter-hooks/#huxx-connect-post-creator-item-hash) hooks.

## If it didn't work

**Posts vanished after a run.** You're in Full sync and the API response didn't contain those items — usually an unpaginated endpoint or a filter rule. Deleted counts appear in the Run Results panel. The posts are gone for good: Full sync deletes permanently, bypassing the trash, so recovery means restoring a backup. Switch to **Create & update** until pagination is configured.

**The first run duplicated existing posts.** Post Matching wasn't enabled (or its field pair didn't match) before the run, so nothing was adopted. Delete the duplicates, configure the Post Matching tab, and run again — use **Preview** first and look for `update (matched)` vs plain `create` actions to confirm matching works.

**Nothing updates even though the API changed.** By default any change to an item's data triggers an update, so first check whether a custom [`item_hash`](/docs/connect/reference/filter-hooks/#huxx-connect-post-creator-item-hash) filter is narrowing the fingerprint — if it hashes only a subset of the item, confirm the changed field is in that subset. In **Update only** mode, also confirm the items match: unmatched items are never created.