Easy Way to Update a SharePoint Content Type
There was a time when I copied a page from one site to another. It was all good until I updated the page, and it would not let me save it. In this case, one possible reason is that the page content type changed from a Site Page to a Wiki Page. So, what can we do about this? Well, we can automatically update the site page’s content type to a Site Page using a REST endpoint. A bit of tips for SharePoint content types can be found at SharePoint Content Type bits of tips!
In this post: Site Address · Method · Headers · Body · Finding the Content Type ID for a different content type · Checking out the page first, if the flow can’t assume it already is · When would you actually use this? · Related reading
Create a flow that will update the page’s content type to a Site Page. Use the Send an HTTP Request to SharePoint action to hit the REST endpoint. First, add the Send an HTTP Request to SharePoint action.
Site Address
Enter the Site Address. It should be the site where the page you want to update is sitting.
Method
For the Method, use the PATCH method. A Patch request lets you do a partial update to a resource. So we will use this method since we are updating a page property.
Headers
Since we are updating a file, we will use two headers for our action. These are the headers:
| Key | Value |
| Content-type | application/json;odata=verbose |
| If-Match | * |
Body
For the body, you need to get the Id of the content type Site Page. It is better to get the Content Type Id dynamically so it will be easier when deploying the flow to another site or tenant. As for me, I checked the content type Id, and it is ‘0x0101009D1CB255DA76424F860D91F20E6C411800B6848D34B694474D993DD9F361193228’.
{
'__metadata': {'type': 'SP.Data.SitePagesItem'},
'ContentTypeId': '0x0101009D1CB255DA76424F860D91F20E6C411800B6848D34B694474D993DD9F361193228'
}For the metadata type, we will be using SP.Data.SitePagesItem because we are updating a file inside the Site Pages document library. Note that you can only update the page if it is checked out. After updating the page’s content type, I suggest publishing it to check the page back in.
Finding the Content Type ID for a different content type
The ID above is specific to my own tenant’s Site Page content type — worth being explicit that this isn’t a universal constant to copy-paste, since a different content type (Wiki Page, or a custom one) needs its own ID looked up the same way. Two ways to actually find it, since the flow above never shows how:
- Through the UI: Site Settings > Site Content Types, click the content type, and the ID sits right in the page’s URL as the
ctype=query string value. - Through REST, if you’d rather script it:
GET /_api/web/lists/getbytitle('Site Pages')/contenttypesreturns every content type attached to that library, each with its ownStringIdfield — the exact value this flow’s Body needs.
The REST route is worth it specifically if this flow needs to run against more than one site or tenant, since the ID for “Site Page” isn’t guaranteed to be identical everywhere — looking it up dynamically inside the flow (rather than hardcoding the one from this post) is what actually makes it portable, which is the exact thing the Body section above already recommends without showing how.
Checking out the page first, if the flow can’t assume it already is
The Body section above notes that the page must be checked out before this PATCH will succeed — fine for a one-off manual fix where you’d check the page out by hand first, but a real gap for a flow meant to run unattended against pages you haven’t personally opened. Add a check-out step ahead of the update action, using another Send an HTTP Request to SharePoint call against the file’s own CheckOut() endpoint:
| Field | Value |
| Method | POST |
| Uri | /_api/web/GetFileByServerRelativeUrl('/sites/YourSite/SitePages/YourPage.aspx')/CheckOut() |
Put this action right before the PATCH action covered in Body above, using the same Site Address. If a page in the flow’s target list might already be checked out (by someone else, or from a prior failed run), this call will error rather than silently succeeding — worth wrapping the whole sequence in a configured run-after / error-handling branch rather than letting the flow just fail if that happens, especially once this is running unattended on a schedule rather than triggered manually.
The other half — “publishing it to check the page back in” from the Body section above — has its own REST equivalent too, for the same reason: a scheduled flow can’t click Publish in the browser. Add a final action after the PATCH, against the same file’s CheckIn() endpoint:
| Field | Value |
| Method | POST |
| Uri | /_api/web/GetFileByServerRelativeUrl('/sites/YourSite/SitePages/YourPage.aspx')/CheckIn(comment='Content type fixed',checkintype=1) |
checkintype=1 checks in as a major version (a straight publish); 0 checks in as a minor/draft version instead, if the library has minor versioning enabled and the page shouldn’t go live immediately. Three actions total, in order — CheckOut, the content-type PATCH, CheckIn — turns the manual two-click “check out, fix, publish” workflow into something that runs unattended end to end.
You can only update the page if it’s checked out — and after updating its content type, check it back in by publishing.
When would you actually use this?
- A page copied between sites silently changed content type from Site Page to Wiki Page, and now refuses to save — this flow fixes it without manually recreating the page.
- You’re migrating or templating pages across multiple sites and need the content-type fix to happen automatically, not as a one-off manual correction.
- You need the same fix to run reliably across more than one tenant — that’s when looking the Content Type ID up dynamically, instead of hardcoding it, actually matters.
Related reading
- SharePoint Content Type bits of tips! — broader content type tips referenced in the intro above.
- SharePoint Content Types: The Good, The Bad, and The Ugly — a deeper look at content types generally, including the Content Type Hub for publishing types across sites.
That’s it! For questions and clarifications, drop a comment below.
App Catalog Authentication Automation Backup Compliance Content Type CSS Flows Google Javascript Limitations List Metadata MFA Microsoft Node NodeJs O365 OneDrive Permissions PnP PnPJS Policy PowerApps Power Automate PowerAutomate PowerPlatform PowerShell React ReactJs Rest API Rest Endpoint Security Send an HTTP Request to SharePoint SharePoint SharePoint List SharePoint Modern SharePoint Online SPFX SPO Sync Tags Teams Termstore Versioning
Hi, thanks for this. I kinda solved my problem with metadata type it was SP.Data.SitePagesItem all the time! MS really have a very good documentation, I can’t really find it!
Hi John. You’re welcome. Actually there’s a part on this blog How to Create Item using Send An HTTP Request to SharePoint where I explained how I got the metadata type. 🙂 Let me know if you have questions.