Connecting WordPress

What connecting WordPress enables

WordPress is one of three ways to get pages into your content inventory — alongside importing by URL or pasting content directly. Connecting it does two things at once:

Nothing about connecting WordPress changes what happens on the WordPress side by itself — it only starts syncing. Publishing back happens later, deliberately, from the audit & editor or the article generator, and always shows you a preview first. See Publishing back for that flow.

Before you start

You’ll need:

• Your site’s address (for example https://example.com) — it must be publicly reachable, since OptimizeCamp connects to it over the internet, not from inside your network.
• A WordPress user account with the Editor or Administrator role. A lower-privilege account can still connect, but sync and publishing will be limited or blocked — more on that below.
• WordPress’s REST API reachable at /wp-json. Most sites have this on by default; some security plugins (a common example is Wordfence or iThemes Security) block it, which shows up as a clear error when you try to connect.

Connecting your site

There are two ways to connect, both starting from Settings → Integrations on a project.

Prefer not to leave the page, or is the authorize screen blocked on your host? Click “Or paste an application password” instead. In wp-admin, go to Users → Profile → Application Passwords, create one named “OptimizeCamp,” and paste the generated password back into OptimizeCamp along with the username it belongs to.

What OptimizeCamp can and can't do

Right after connecting, OptimizeCamp checks what the account you connected is actually allowed to do on your site, and shows it back to you as two capability chips:

If either capability is missing, OptimizeCamp doesn’t just fail silently — it lists the specific blocker under the connection card in plain language, for example that this user can’t edit posts so content won’t sync, with a pointer to fix it by connecting an Editor or Administrator account instead.

How syncing works

The first sync after connecting pulls in every post and page on your site — published, draft, scheduled, and pending review. After that, syncs are incremental: OptimizeCamp remembers the most recent “modified” timestamp it has seen and only asks WordPress for what changed since then, which keeps repeat syncs fast.

You can trigger a sync manually at any time with the Sync now button on the connected card, and the settings page polls for progress live — you’ll see a status line like “Fetching posts (page 2)” or “Processing 14 of 38” while it runs. Every sync also checks for posts that were deleted on the WordPress side and archives the matching item in your library, so your inventory doesn’t quietly drift out of sync with reality.

If you’ve made local edits to a page inside OptimizeCamp and the same post also changed on WordPress before you published, the sync doesn’t guess which version wins — it flags the item as a conflict and leaves your local edit untouched until you decide.

How publishing back stays safe

Getting content into WordPress correctly matters as much as getting it out. A few things are true of every publish, by design:

• Generated articles only ever reach WordPress as drafts. A brand-new article from the generator is never pushed live directly — it lands as a WordPress draft, and updating it further only becomes possible once you’ve published that draft yourself from wp-admin.
• Updates never touch publish status. When an accepted fix pushes onto an existing post, OptimizeCamp sends only the content and title — never a status change — so a live post stays live and a draft stays a draft.
• A conflict guard runs before every update. OptimizeCamp checks WordPress’s own “last modified” stamp immediately before pushing. If the post changed on WordPress after your last sync — someone edited it directly in wp-admin, say — the publish is blocked rather than silently overwriting that change.
• WordPress’s own revision history stays intact. Because updates go through the normal WordPress REST update endpoint, each one creates a native WordPress revision, so you always have wp-admin’s own revision compare as a second safety net on top of OptimizeCamp’s own version history.

For the full publish flow — the diff preview, the two publish modes, and what happens after — see Publishing back.

Disconnecting

Click Disconnect on the connected card at any time. This revokes the stored credentials — syncing and publishing to that site stop immediately — but every page you’ve already synced stays exactly where it is in your content library. Nothing is deleted. Reconnecting the same site later revives the same connection in place rather than creating a duplicate.

How your credentials are protected

Your application password is never stored in plain text. It’s encrypted at rest with its own randomly generated key, and that key is itself encrypted by a master key — so decrypting your credentials requires two layers, not one. The plaintext password only ever exists transiently, inside the exact sync or publish call that needs it, and it never appears in logs, error messages, or anything sent back to your browser.