Exploring SharePoint REST API Endpoints

The SharePoint REST API is organized entirely around one root path — {site-url}/_api/ — with everything else (lists, files, users, search) hanging off web, site, or a dedicated service beneath it. Here’s a reference list of the endpoints you’ll actually reach for, plus a working example calling one from plain JavaScript.

In this post: Site and web endpoints · List and item endpoints · File and folder endpoints · User and group endpoints · Search endpoints · Term store and workflow endpoints · A working example · When would you actually use this? · Related reading

Site and web endpoints

Current site collection: _api/site
Current web: _api/web
Subsites of the current web: _api/web/webs

Worth flagging: a bare /sites/{site-id} path (no _api) is a Microsoft Graph convention, not SharePoint’s own REST API — the two are easy to conflate since they cover overlapping data, but they’re different APIs with different root paths and different auth scopes.

List and item endpoints

Get all lists: _api/web/lists
Get list items: _api/web/lists/getByTitle('{list-title}')/items
Add a list item: POST to the same items endpoint above
Update a list item: MERGE/PATCH to _api/web/lists/getByTitle('{list-title}')/items({item-id})
Delete a list item: DELETE to the same item endpoint

File and folder endpoints

Files in a library: _api/web/getFolderByServerRelativeUrl('{library-relative-url}')/files
Folders in a library: _api/web/getFolderByServerRelativeUrl('{library-relative-url}')/folders
Get a file by path: _api/web/getFileByServerRelativeUrl('{file-relative-url}')
Upload a file: POST to _api/web/getFolderByServerRelativeUrl('{library-relative-url}')/files/add(overwrite=true,url='{filename}')

User and group endpoints

Current signed-in user: _api/web/currentuser
A specific user by ID: _api/web/getUserById({user-id})
All site users: _api/web/siteusers
All site groups: _api/web/sitegroups

Search endpoints

Basic search query (GET, simpler queries): _api/search/query?querytext='{query}'
Content search (POST, more complex queries — refiners, sorting): _api/search/postquery
Scoped people/department search: _api/search/query?querytext='Department:{department-name}'

Term store and workflow endpoints

Taxonomy session (term store access): _api/SP.Taxonomy.TaxonomySession/getTaxonomySession(termStoreId)
Term sets by name: _api/SP.Taxonomy.TermStore/getTermSetsByName('{term-store-name}')
Workflows on a list: _api/web/lists/getByTitle('{list-title}')/workflows
Start a workflow instance: _api/SP.WorkflowServices.WorkflowInstanceService/StartWorkflowOnListItemBySubscriptionId

Worth noting on this last group: SharePoint 2010 workflows were retired in 2020, and SharePoint 2013 workflows were fully retired on April 2, 2026 — these workflow endpoints are effectively legacy at this point, not something to build a new integration against. Power Automate is the actual current answer for workflow orchestration.

A bare /sites/{site-id} path is a Microsoft Graph convention, not SharePoint’s own REST API — the two are easy to conflate but have different root paths and auth scopes.

A working example

Retrieving every item from a list named “Tasks” and rendering the titles into a div:

document.addEventListener("DOMContentLoaded", function() {
    var siteUrl = "https://your-sharepoint-site-url";
    var listName = "Tasks";
    var endpointUrl = siteUrl + "/_api/web/lists/getByTitle('" + listName + "')/items";

    var xhr = new XMLHttpRequest();
    xhr.onreadystatechange = function() {
        if (xhr.readyState === XMLHttpRequest.DONE) {
            if (xhr.status === 200) {
                var response = JSON.parse(xhr.responseText);
                displayListItems(response.value);
            } else {
                console.error("Failed to retrieve list items. Error: " + xhr.status);
            }
        }
    };
    xhr.open("GET", endpointUrl, true);
    xhr.setRequestHeader("Accept", "application/json;odata=nometadata");
    xhr.send();
});

function displayListItems(items) {
    var outputDiv = document.getElementById("output");
    outputDiv.innerHTML = "List Items:";
    items.forEach(function(item) {
        outputDiv.innerHTML += "" + item.Title + "";
    });
}

Replace the site URL and list name with your own. This example is read-only (a GET), so it doesn’t need the X-RequestDigest header — add it if you extend this to create, update, or delete items.

When would you actually use this?

You’re integrating SharePoint data into an external application and need to know which endpoint actually covers what you’re after.
You’re building a script editor web part or classic-page customization where pulling in PnPjs isn’t worth it for a single call.
You need to know whether something’s a SharePoint REST concept or a Graph API concept before debugging why a URL pattern from one doesn’t work against the other.

How to Send an HTTP Request in SharePoint via JavaScript — the digest/header mechanics behind the GET example shown here, plus the POST case.
CSOM, JSOM and REST API in SharePoint: Quick Overview — how REST compares to the other two client-side development models.

That’s the reference list plus a working example. Missing an endpoint you need? Ask in the comments.