When to use Send an HTTP request to SharePoint

Short answer: use the standard SharePoint actions first. Reach for "Send an HTTP request to SharePoint" only when a standard action cannot do the job, for example when you need to change who can open one item, or read a list in a way "Get items" does not allow. The action sends a SharePoint REST call for you. Microsoft's own note on it is short and serious: "This action may execute any SharePoint REST API you have access to. Please proceed with caution." Start with a read-only call on a test list.

Menu and action names in Microsoft 365 change from time to time. The exact names may differ on your screen.

What the action is

You build flows at https://make.powerautomate.com. The SharePoint connector has an action named "Send an HTTP request to SharePoint". Microsoft's connector page describes it this way: "Construct a SharePoint REST API to invoke."

The action asks for five things:

Site Address. Microsoft's example is https://contoso.sharepoint.com/sites/sitename.
Method. This is the HTTP method, such as GET or POST.
Uri. Microsoft's example is _api/web/lists/getbytitle('Documents').
Headers. Microsoft's field text: "Enter JSON object of request headers".
Body. Microsoft's field text: "Enter request content in JSON".

In plain words: you write the address of one SharePoint REST endpoint, pick GET or POST, and the flow sends it using your own connection. Because it uses your connection, it can do whatever your account can do in that site.

Try the standard actions first

The standard actions are easier to read and easier to hand to the next person. They also show clear fields in the flow designer. Before you use the HTTP action, check whether one of these already covers your need:

"Get items" and "Get item" to read.
"Create item" and "Update item" to write.
"Resolve person" for a Person column. The connector page says it "Returns a single matching user value so it can be assigned to a column of type person."

If your problem is a Person column that will not save, read "Flow cannot set a Person column: user could not be found" before you build a REST call. If your problem is a flow that stops at 100 rows, read "Power Automate Get items stops at 100 rows: how to get them all". Those guides fix the problem with standard actions.

When the HTTP action is worth it

Here are three jobs where a standard action may not be enough. Test each one on a copy of your list first.

Give one item its own permissions. By default a list item gets its access from the list. Microsoft says: "By default, a securable object inherits the permissions of its parent." To give one item its own access, you break that inheritance and then add people. The REST service has a call for this, named breakroleinheritance, and a second named addroleassignment.
Read items with a filter, a field list and a sort in one call. The REST service supports the query options $select, $filter, $orderby and $top.
Update a list item in a way the standard action does not offer. Microsoft's REST page shows an update that uses the MERGE method.

Our advice, not a Microsoft rule: if a standard action works, use it. Every HTTP call is one more thing that only a person who reads REST can fix.

Example 1. Read items safely (GET)

A GET call only reads. It changes nothing, so it is the safest way to learn the action.

In your flow, add the SharePoint action "Send an HTTP request to SharePoint".
Set Site Address to your site, for example https://contoso.sharepoint.com/sites/sitename. Use your own site.
Set Method to GET.
In Uri, use this form, with your own list name: _api/web/lists/getbytitle('Requests')/items?$select=Title,Id&$top=10
In Headers, enter a JSON object with an Accept value. Microsoft's REST pages show this Accept value: application/json;odata=verbose. In the Headers box it looks like {"Accept": "application/json;odata=verbose"}.
Save and run the flow. Open the run history and look at the action's output.

Microsoft's REST page warns about size. It says: "By default, this will return the first 100 items." The $top option in your Uri sets how many to ask for. The same page says: "The OData $skip query parameter doesn't work when querying list items." Microsoft points to the $skiptoken option for paging instead. Our advice, not a Microsoft rule: if you need to read many rows, use "Get items" with Pagination turned on, which is easier to maintain.

Example 2. Update one item (MERGE)

Microsoft's REST page shows an update as a POST call with two header values: X-HTTP-Method set to MERGE, and If-Match. It also says which value must appear in the body: "To do this operation, you must know the ListItemEntityTypeFullName property of the list and pass that as the value of type in the HTTP request body."

Make a test list with a Title column and one text column.
Add a GET call first, with $select=ListItemEntityTypeFullName on the list, to read the type name.
Add the update call. Set Method to POST. Put the item Id in the Uri, in this form: _api/web/lists/getbytitle('Requests')/items(12)
In Headers, set Accept, Content-Type, If-Match and X-HTTP-Method as Microsoft's REST page shows them.
In Body, send a JSON object with the type name from step 2, and the one column you want to change.
Test on one item. Open the item in the list and check the change and the version history.

Microsoft's page explains the If-Match value: "To force an overwrite of the item regardless of version, set the ETag value to "*"." It also says: "If you do not specify an ETag, SharePoint overwrites the item regardless of version." Plan for that: another person's edit can be replaced.

Person columns are a special case. Our advice, not a Microsoft rule: update a Person column with the standard "Update item" action and "Resolve person" first. Do not guess a REST body for it.

Example 3. Give one item its own permissions

This is the riskiest example. Microsoft's REST page on list permissions says: "By default, a securable object inherits the permissions of its parent." Changing permissions needs a site owner or someone with the same rights. Microsoft says that sites, lists and list items are all securable objects.

One way to start:

Use a test list with fake rows. Never use a live list for your first test.
Send a POST call to the breakroleinheritance endpoint. Microsoft's page shows it on a list: _api/web/lists/getbytitle('Requests')/breakroleinheritance(true). If you need it on one item, get help before you run it on real data.
Send a POST call to the addroleassignment endpoint to give one person or group a permission level.
Open the item in the list and check who has access.
Write down how to undo it before you run it on real data.

Microsoft's page shows breakroleinheritance(true) and the role call addroleassignment(principalid=...,roledefid=...). The IDs come from other GET calls. The exact names may differ between pages.

Two cautions. First, a view or a filter does not hide data. Only permissions do. For a simple version of "each person sees their own rows", read "Let each person see only their own items in a SharePoint list". Second, many items with their own permissions are hard to audit. Our advice, not a Microsoft rule: keep a list of which items you changed.

What to avoid

Do not run a call you do not understand. Microsoft's own warning applies to every call.
Do not test on a live list. Copy the list or make a small test list.
Do not paste a REST call from the web without reading each part: the method, the Uri and the body.
Do not build a flow that triggers on an item change and then updates the same item through the HTTP action without a guard. It can loop. Read "Power Automate flow keeps running itself over and over".
Do not hide the flow's purpose. Add a note in the flow that says what each HTTP call does.
Do not page through a list that people are editing at the same time. Microsoft's REST page says paging in OData is ordinal, so if other people delete items between your calls, items can be skipped.

A note on users in queries

Microsoft's REST page on queries says that users are represented by the friendly name: "In the SharePoint REST service, users are represented by the user's friendly (display) name, and not their alias or domain\alias combination." It also says: "Membership-based user queries are not supported." If a filter on a Person column returns nothing, check that you are filtering on the display name.

Honest limits

A REST call is code. It does not show you a form with the right fields. A small spelling mistake in the Uri can return an error or, for a write, change the wrong thing. The action runs with your connection, so it can do what your account can do. For a flow that outlives its builder, see "The person who built your flows left: what happens and what to do". Microsoft's pages for REST were written for developers, so the steps above are a starting point for a test list, not a full guide to the whole REST service.

When to get help

You can build all of this yourself in Microsoft 365. If you would rather have it built and tested for your team, I do that. A tracker like this is a fixed price: $5,000 for one, built in 2 weeks. See "What a SharePoint tracker costs to build". Bring one example of the problem to a free call.

Tell me what's still manual

I am Al Davies. I run 250 High Street LLC and build SharePoint trackers and Power Automate flows for operations teams. I work remotely. The first call is free, and I will not try to sell you anything.

See trackers I built: Tools I built

FAQ

Is Send an HTTP request to SharePoint safe?

It is as safe as the call you send. A GET call only reads. A POST call can change or remove data. Microsoft's connector page warns that the action "may execute any SharePoint REST API you have access to." Test on a copy first.

Do I need to know how to code?

You do not need to write a program, but you do need to read a REST address, a method and a small JSON body. If that feels like too much, use the standard actions instead.

Why does my GET call return only some of my items?

Microsoft's REST page says: "By default, this will return the first 100 items." Set $top, or use "Get items" with Pagination turned on.

Can I use it to update a Person column?

Our advice, not a Microsoft rule: try "Update item" with "Resolve person" first. See "Flow cannot set a Person column: user could not be found".

Does a view or filter stop people from seeing items?

No. Views are not security. Only permissions control who can open an item.