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:
- Configuration card → Sync Mode. Default is Create & update (
no_delete) — keep it while testing.- 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.- Items match primarily by Unique Key (stored in post meta on every write).
- 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.
- 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
/productsreturns 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 insists on a key present in every item: items whose key is unresolved are skipped at runtime.
New to APIs? Read this first
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 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.
- Open the Post Matching tab and switch on Match API items to existing posts.
- 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). - 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 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 and 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 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.