Counting Document Library Items in Power Automate (and fixing “Folder Not Found” 404) — the right way

When you need to compare the number of items in a document library across two SharePoint sites, you have two common options:

1. Use standard SharePoint connector actions (e.g., Get files (properties only)), then count items.
2. Use SharePoint REST via “Send an HTTP request to SharePoint” to retrieve the library’s ItemCount (fast) or a folder’s ItemCount (scoped).

In practice, for counting only (not listing all documents), REST is usually the best approach because it avoids enumerating thousands of files and hitting connector payload limits. The Microsoft Learn guidance explicitly positions “Send an HTTP request to SharePoint” as the escape hatch when standard actions don’t fit your needs. (Microsoft Learn)

Important for public documentation: I’m using neutral placeholders (e.g., https://contoso.sharepoint.com/sites/ExampleSite and Documents) so you can paste this into a public blog safely.

1) Key concept: a Document Library is a List

A SharePoint document library is effectively a list (BaseTemplate 101). That’s why you can read properties like ItemCount from the Lists REST endpoints. Microsoft Learn’s REST documentation covers how to work with lists and their properties via REST. (Microsoft Learn)

This matters because:

• Counting items should be done with list metadata (ItemCount)
• Listing items/files should be done with queries that enumerate content (slower, heavier)

2) Recommended pattern: Count library items using REST ItemCount

Why this is the best pattern

• Fast (metadata call, not enumerating files)
• Stable (no pagination)
• Avoids 200MB output issues that can happen when actions aggregate huge arrays of results (Microsoft Learn)

Power Automate steps (for each site)

Step A — Add action: Send an HTTP request to SharePoint

• Site Address: https://contoso.sharepoint.com/sites/ExampleSite
• Method: GET
• Uri:

/_api/web/lists/getbytitle('Documents')?$select=Title,ItemCount,RootFolder/ServerRelativeUrl&$expand=RootFolder

This uses standard SharePoint REST list access patterns described by Microsoft Learn. (Microsoft Learn)

Step B — Add Parse JSON

Parse the HTTP response. Minimal schema:

{
  "type": "object",
  "properties": {
    "d": {
      "type": "object",
      "properties": {
        "Title": { "type": "string" },
        "ItemCount": { "type": "integer" },
        "RootFolder": {
          "type": "object",
          "properties": {
            "ServerRelativeUrl": { "type": "string" }
          }
        }
      }
    }
  }
}

Step C — Store count in a variable

Use Set variable (Integer):

int(body('Parse_JSON')?['d']?['ItemCount'])

Step D — Repeat for the second site/library and compare

• SourceCount vs TargetCount
• Or compute the delta:

sub(variables('SourceCount'), variables('TargetCount'))

3) When you truly need folder counts (and why you got 404 “Folder Not Found”)

Your error:

• statusCode: 404
• message: "Folder Not Found"

That means the endpoint resolved, authentication worked, but the folder path you provided does not exist exactly as written.

Microsoft Learn shows that folder retrieval expects the correct server-relative URL in GetFolderByServerRelativeUrl(...). (Microsoft Learn)

The correct endpoint pattern (Folder)

/_api/web/GetFolderByServerRelativeUrl('/sites/ExampleSite/Shared Documents/SomeFolder')?$select=Name,ItemCount,ServerRelativeUrl

Common reasons for 404 in folder calls

• You used an absolute URL instead of server-relative (https://... instead of /sites/...)
• The site path is wrong (/sites/ vs /teams/)
• The library URL segment is not what you assumed (Shared Documents vs a localized display name)
• Special characters/spaces weren’t encoded consistently

Microsoft Learn’s folder/file REST guidance also calls out practical constraints and nuances around these endpoints. (Microsoft Learn)

4) Bulletproof approach: discover the correct library root, then build folder URLs from it

To avoid guessing:

Step 1 — Read the library root folder URL (REST)

/_api/web/lists/getbytitle('Documents')?$select=RootFolder/ServerRelativeUrl&$expand=RootFolder

Step 2 — Use that value to build the folder endpoint

/_api/web/GetFolderByServerRelativeUrl('<RootFolderServerRelativeUrl>/SomeFolder')?$select=ItemCount

This dramatically reduces “Folder Not Found” errors because you stop hardcoding uncertain paths.

5) Alternative (not recommended for big libraries): Count by enumerating files

Option: Get files (properties only) + length()

This works for small libraries, but it’s easy to hit:

• pagination requirements
• performance issues
• output size limits (notably when results become huge)

Microsoft Q&A threads commonly recommend enabling pagination for large libraries, but that still doesn’t remove payload risks. (Microsoft Learn)

Counting expression:

length(body('Get_files_(properties_only)')?['value'])

6) Practical recommendation for your scenario

If your goal is just:

“compare how many items exist in library A (site 1) vs library A (site 2)”

Use:

• REST ItemCount on both sites/libraries

Only use folder endpoints if you explicitly need:

• count per subfolder
• or deeper structure checks

Final tables

Steps summary (Power Automate implementation)

Technical decision matrix