Publish SharePoint List Items to WordPress with Power Automate

The safest design is one-way publishing: SharePoint owns the approved source record, Power Automate creates or updates a WordPress post through the REST API, and SharePoint stores the returned WordPress post ID.

That is not a general two-way sync. Two systems cannot both be authoritative without conflict rules.

Fact-checked against current Microsoft and WordPress developer documentation on 24 August 2026.

Prerequisites

You need:

a WordPress site with the REST API available over HTTPS;
a dedicated WordPress user with only the capabilities required to manage the target content;
a WordPress Application Password for that integration user;
a Power Automate environment allowed to use the chosen HTTP or custom-connector route;
a SharePoint list with an approval and publishing state.

WordPress introduced Application Passwords for API authentication in WordPress 5.6. They are individually revocable and intended for API clients. Never store the user's normal WordPress password in a flow.

Microsoft's generic HTTP actions and custom connectors can require Premium licensing and may be restricted by data-loss-prevention policies. Verify the current action and environment before building.

Design the SharePoint list

Use fields such as:

Title
Body
Excerpt
WordPress status: draft, pending or publish
WordPress post ID
WordPress URL
Publish approved
Content hash or source version
Last synced at
Sync status
Error summary

Make the WordPress post ID the durable link between systems. Do not search by title to decide whether the post already exists.

Trigger only approved changes

Use a SharePoint trigger with conditions so the flow continues only when publishing is approved and the current source version has not already succeeded.

For high-risk publishing, use an approval or explicit status transition rather than treating every list edit as permission to change the public website.

Create a new WordPress post

The WordPress Posts endpoint creates a post with:

POST https://example.com/wp-json/wp/v2/posts

Send the fields required for your content model, such as title, content, excerpt and status. Use the dedicated integration identity and Application Password over HTTPS.

Start with draft, inspect the rendered result in WordPress and move to publish only when the process has a deliberate approval gate.

After a successful response, save the returned numeric post ID and link to the SharePoint item.

Update an existing post

When WordPress post ID is present, update that exact item:

POST https://example.com/wp-json/wp/v2/posts/<id>

Before sending, compare the SharePoint source version or a content hash with the last successful value. Skip the API call when nothing material changed.

Images need their own route

A SharePoint image URL is not automatically a WordPress media item. If the post needs a featured image:

retrieve approved file content;
upload it to the WordPress media endpoint;
store the returned media ID;
assign that ID as featured_media on the post.

Check image rights, size, file type and alt text. Do not publish an image merely because it was attached to a list item.

Protect the credential

Give the integration user the least privilege that works.
Use an Application Password, not the user's interactive password.
Restrict access to the flow and connection.
Rotate and revoke the Application Password when ownership changes.
Do not include the credential in Compose outputs, error emails or run-history notes.

WordPress stores Application Passwords hashed and shows the generated value only at creation. Save it through your approved secret-handling route at that point.

Prevent loops and duplicates

The flow should write sync metadata back to SharePoint. Those writes can retrigger the flow, so exclude metadata-only changes with trigger conditions or a source-version check.

Use this decision:

no WordPress post ID: create;
post ID present and source changed: update;
post ID present and source unchanged: stop;
API returns 404 for stored ID: route for review rather than creating a duplicate silently.

Failure handling

Record the HTTP status, WordPress post ID, source item ID and a safe error summary. Treat 401/403 as credential or permission faults, 400 as a content or schema problem, and 5xx as a possible transient service failure.

Do not automatically retry a create request without checking whether WordPress created the post before the connection failed.

Sources

Review the publishing boundary

Bring a redacted create response, update response and trigger condition to the Power Automate Builders Space.