Publish WordPress Posts from SharePoint with Power Automate

You can use a SharePoint list as an editorial queue and Power Automate to create draft posts in WordPress.

It is a useful pattern when contributors already work in Microsoft 365 but only a small publishing team should touch WordPress. SharePoint holds the request, review state and publishing result. Power Automate calls the WordPress REST API. WordPress remains the public content system.

There are three important boundaries:

1. Power Automate's general HTTP action is a Premium connector. This is not a “no-premium hack”.
2. WordPress Application Passwords are credentials. Do not paste one into a Compose action or leave it visible in run history.
3. A flow run is not a publishing transaction. Store the WordPress post ID and make retries safe, or a failed run can create duplicates.

This guide builds the safe core first. Copilot, a Power App, Teams and AI review are optional additions—not prerequisites for publishing a WordPress draft.

The architecture

Contributor
  -> SharePoint editorial list
  -> approval/status gate
  -> Power Automate cloud flow
  -> WordPress REST API
  -> WordPress draft
  -> WordPress post ID and URL written back to SharePoint

The WordPress REST API is available on each WordPress site. Its standard endpoints include:

• /wp-json/wp/v2/posts for posts;
• /wp-json/wp/v2/media for media;
• /wp-json/wp/v2/categories for categories; and
• /wp-json/wp/v2/tags for tags.

Creating a draft post is one request. Uploading an image, resolving a category name and publishing after approval are separate operations.

What you need

• A SharePoint Online list.
• A Power Automate environment and licence that covers the Premium HTTP action.
• A WordPress site served over HTTPS with the REST API available.
• A dedicated WordPress integration user with only the capability required to create/edit the intended post type.
• A WordPress Application Password created for this integration.
• An owner for failures, credential rotation and WordPress schema changes.

Do not use a personal site administrator account. If the employee leaves, the integration should not become an archaeological dig.

Step 1: create the SharePoint editorial queue

Start with these columns:

Column	Type	Purpose
Title	Single line of text	WordPress post title
Body	Multiple lines of text	Post body; decide whether it contains HTML or plain text
Excerpt	Multiple lines of text	Optional WordPress excerpt
RequestedSlug	Single line of text	Optional controlled URL slug
PublishDecision	Choice	Draft, Approved, Rejected
FlowStatus	Choice	Not queued, Queued, Publishing, Created, Failed
WordPressPostId	Number	Durable identity returned by WordPress
WordPressUrl	Hyperlink	Resulting preview/public URL
LastAttemptAt	Date and time	Operational evidence
LastError	Multiple lines of text	Sanitised support message

Keep the editorial decision separate from the technical flow state. Approved describes what an editor decided. Publishing or Failed describes what the integration is doing.

If the body is rich text, establish the contract before building the flow. SharePoint rich text, Markdown and WordPress block markup are not interchangeable. The simplest reliable V1 accepts reviewed HTML and posts it as WordPress content. Sanitise and preview it in a non-production site first.

Step 2: create a dedicated WordPress Application Password

WordPress has shipped Application Passwords since version 5.6. The official authentication guidance supports using a WordPress username and Application Password over HTTPS for remote REST requests.

In WordPress:

1. Create or select a dedicated integration user.
2. Give it the minimum role/capabilities required to create and edit the intended posts.
3. Open the user's profile.
4. Under Application Passwords, create one named for this flow and environment.
5. Copy the generated value once and place it into the approved secret-management route.

The newer WordPress Application Password guidance confirms that each password is individually revocable and should be rotated like any other secret.

Do not use the person's normal WordPress password. Do not share one Application Password between development and production.

Step 3: protect the credential in Power Automate

Microsoft's secure cloud-flow guidance warns against hard-coding passwords or API keys because people with access to a flow can inspect inputs and outputs.

For a governed production build:

• retrieve the secret from an approved store such as Azure Key Vault where your licensing and architecture support it;
• use environment variables/connection references inside a solution for non-secret configuration such as the WordPress base URL;
• enable Secure inputs and Secure outputs on actions that handle the credential; and
• restrict who can edit the flow.

Secure inputs/outputs reduce run-history exposure. They do not make every flow editor unable to discover how the authentication works. Treat flow co-ownership as privileged access.

For a short proof of concept, a platform administrator may configure Basic authentication directly in the HTTP action. Do not call that production secret management.

Step 4: trigger only approved work

Create an automated cloud flow using SharePoint's When an item is created or modified trigger.

Immediately check:

• PublishDecision is Approved;
• FlowStatus is Queued or Failed when an operator has explicitly requested a retry; and
• WordPressPostId is blank for a create operation.

If those conditions are false, terminate successfully without calling WordPress.

Why the explicit queue state? The same flow will update the SharePoint item after WordPress responds, which fires the SharePoint trigger again. A flow that runs on every modification without a gate can call itself repeatedly.

Before the HTTP call, update FlowStatus to Publishing, set LastAttemptAt, and clear the old sanitised error. This is an operator signal, not a transactional lock. Keep trigger concurrency low and make the WordPress side idempotent using the stored post ID.

Step 5: create a WordPress draft

Add an HTTP action:

• Method: POST
• URI: https://YOUR-SITE.example/wp-json/wp/v2/posts
• Authentication: Basic
• Username: the dedicated integration username
• Password: the Application Password from your approved secret route
• Content-Type: application/json

Use a body like this, inserting dynamic values through the designer:

{
  "title": "@{triggerBody()?['Title']}",
  "content": "@{triggerBody()?['Body']}",
  "excerpt": "@{triggerBody()?['Excerpt']}",
  "slug": "@{triggerBody()?['RequestedSlug']}",
  "status": "draft"
}

The exact internal names of SharePoint columns may differ. Select the dynamic content where possible rather than typing guessed names.

Start with draft, even when the SharePoint item is approved. That gives the publishing team one final WordPress preview for theme rendering, links, images, categories, SEO fields and unsupported block markup. Change to direct publish only after the organisation has explicitly accepted the resulting control and recovery model.

The official WordPress Posts endpoint reference is the source of truth for accepted fields and response values.

Step 6: store the returned WordPress identity

A successful create response includes the new post's WordPress id, link, status and other fields.

Write back at least:

• WordPressPostId = the returned id;
• WordPressUrl = the returned link or your preview route;
• FlowStatus = Created;
• LastError = blank; and
• LastAttemptAt = the current time.

The numeric WordPress ID is the durable link between systems. Do not use the title as identity. Titles change. Slugs can also change and WordPress may normalize or uniquify them.

For later edits, call:

POST /wp-json/wp/v2/posts/{WordPressPostId}

Do not call the create endpoint again when the ID already exists.

Step 7: make failures visible and retries safe

Put the WordPress call and SharePoint success update inside a Try scope. Add a Catch scope configured to run when Try fails, times out or is skipped unexpectedly.

In Catch:

• set FlowStatus to Failed;
• store a sanitised error code/message, never the credential or full Authorization header;
• notify the named operator; and
• leave WordPressPostId untouched if it already exists.

There is one hard case: WordPress creates the post, but the SharePoint write-back fails. Retrying the create request can make a duplicate.

Reduce that risk by:

1. using a deterministic requested slug or external correlation value;
2. searching WordPress for that value before retrying a create;
3. treating an ambiguous timeout as needs reconciliation, not “definitely failed”; and
4. giving the operator a way to enter the discovered WordPress ID before retrying.

A title search is not enough. Two posts can legitimately share similar titles.

Step 8: add featured media only when the core works

WordPress media is a separate resource. The Media endpoint accepts a POST /wp/v2/media upload and returns a media ID.

A complete image route is:

1. retrieve the approved image bytes;
2. upload them to /wp/v2/media with the correct content type and filename;
3. set useful alternative text in WordPress;
4. capture the returned media ID; and
5. include that ID as featured_media when creating/updating the post.

Do not simply pass a SharePoint sharing URL into featured_media. WordPress expects a WordPress media ID.

Common failures

401 or 403 from WordPress

Check HTTPS, username, Application Password, user capabilities and whether the host or security layer is stripping the Authorization header. WordPress documents server-specific header troubleshooting in its REST API FAQ. Change web-server configuration only with the site owner's approval.

The flow creates duplicates

The create path is being retried without a stored/reconciled WordPress ID, or the SharePoint trigger gate is too broad. Fix state and idempotency; do not add a longer delay and hope.

WordPress receives broken JSON

Use the HTTP action's JSON body editor and dynamic values. Avoid building the entire JSON document with string concatenation, where quotes, line breaks and HTML can corrupt the payload.

The body looks wrong in the WordPress editor

Confirm whether the SharePoint column contains plain text, HTML or another format. A REST-created HTML body may render on the front end but not behave like hand-authored WordPress blocks in the editor. Test the editing handover, not only the public preview.

The flow owner leaves

The flow, SharePoint connection, Premium licence and secret retrieval route need organisational ownership. Add another appropriate owner, document the service account/integration user and test credential rotation before go-live.

Production acceptance checklist

• Premium connector licensing is confirmed for this exact flow model.
• WordPress uses HTTPS and a dedicated least-privilege integration user.
• Application Password is stored through the approved secret route.
• Sensitive inputs and outputs are hidden from ordinary run-history inspection.
• SharePoint has separate editorial and technical status fields.
• The trigger ignores updates that are not explicitly queued.
• New content is created as a WordPress draft first.
• WordPress post ID and URL are written back.
• Retry logic cannot blindly create a second post after an ambiguous timeout.
• Errors reach a named operator without exposing credentials.
• A second owner can operate the flow and rotate the credential.
• Development and production use separate WordPress credentials.

For more Power Automate builds with honest licensing, failure and ownership boundaries, join the Power Automate Mastery Space.

Frequently asked questions

Can Power Automate publish to WordPress?

Yes. The WordPress REST API lets an authenticated client create or update posts. In Power Automate, the general HTTP action can call /wp-json/wp/v2/posts and send a JSON post body.

Is the Power Automate HTTP action free with Microsoft 365?

Do not assume so. The general HTTP connector appears in Microsoft's Premium connector catalogue. Confirm the current Power Automate licensing for the flow owner, process and users before production.

Should I use my normal WordPress password?

No. Use a dedicated least-privilege WordPress integration user and a separately revocable Application Password over HTTPS. Keep the credential out of ordinary flow inputs, outputs and documentation.

How do I stop duplicate WordPress posts?

Store the WordPress post ID in SharePoint and use the update endpoint for later changes. Treat timeouts after a create request as ambiguous and reconcile by a deterministic slug/correlation value before retrying.

Can the flow set a featured image?

Yes, but upload the image to /wp/v2/media first, capture the returned media ID, then pass that ID as featured_media when creating or updating the post.