Skip to content

Odata

The OData data source allows you to get data from the following APIs

  • Microsoft Graph: both v1.0 or beta endpoints.
  • SharePoint REST API: the current site or an other site in your tenant. Supports v1.0 or v2.0,
  • Azure Active Directoy secured API like an Azure function, Azure Web Application, etc.
  • Anonymous API

    "OData API types

Microsoft Graph

The URL supports the following formats. Tokens can also be used to construct your URL: * me * /me * https://graph.microsoft.com/v1.0/me * https://graph.microsoft.com/beta/me * me/events?$filter=startswith(subject, 'ship')

Before using a Microsoft Graph resource, you need to ensure you allowed the correct API permissions at tenant level. Because you can't define API permissions through the Web Part package declaratively (i.e webApiPermissions), we recommend you to use the PnP Office 365 CLI to add correct permissions for your API:

o365$ spo serviceprincipal grant add --resource 'Microsoft Graph' --scope 'Mail.Read'

SharePoint REST API

The URL supports the following formats. Tokens can also be used to construct your URL

  • /_api/ (will target the current root site if you don't specify anything)
  • <your_site>/_api/ (ex: http://mycompany.sharepoint.com/sites/intranet/_api/lists)
  • /_api/v2.0/sites/{site.id}/drive/list/items?expand=fields(select=FileLeafRef,BaseName,FileRef,FSObjType)&$top={itemsCountPerPage}
  • etc.

You can also use query parameters supported by the API

Azure Active Directory secured API

  1. Follow this procedure to set up your Azure Active Directory application. Don't forget to add at least the 'user impersonation' permission to be able to call the API endpoint.

Before using an AAD secured resource, you need to ensure you allowed the correct API permissions at tenant level. Because you can't define API permissions through the Web Part package declaratively (i.e webApiPermissions), we recommend you to use the PnP Office 365 CLI to add correct permissions for your API:

`o365$ spo serviceprincipal grant add --resource '<aad_app_display_name>' --scope 'user_impersonation'`
  1. Allow your SharePoint domain (ex: https://mycompany.sharepoint.com) as allowed origin in the service or application CORS (Cross-origin resource sharing) settings. Here a procedure for an Azure function.

Anonymous

You can also call an API endpoint with no specific authentifcation like an Azure HTTP trigger Function with function code. By default, we use the demo OData v4 services provided by https://www.odata.org/odata-services/ to demonstrate the capability.

Set HTTP headers or body

The only method allowed are GET or POST. For each, you have the ability so set your own HTTP headers. The value must be a valid JSON value:

{
    "Content-Type": "application/json;odata=verbose",
    "Accept": "application/json",
    ...
}

If you specify a POST request, you can also benefit of builtin tokens.

{
    "ItemsCount": "{itemsCountPerPage}",
    "MyProperty": "My Value",
    ...
}

Pagination

For each API type, you can control how the results will be paginated in order to improve performances.

"OData paging

Dynamic paging

Use a Dynamic paging if the underlying API you are using supports paging mechanisms (likely using $top and $skip or $skipToken tokens, for instance Microsoft Graph or SharePoint REST API).

Use server-side paging

Some APIs like Microsoft Graph or the SharePoint REST API provide a server-side paging functionality (see https://docs.microsoft.com/en-us/graph/paging for more information). Basically, it allows you to paginate results more easily by using a pre-calculated next page link URL instead of building it manually.

If checked, the paging will be based on the @odata.nextLink value from the HTTP response. It means when you will click on the next page button, this value will be used to get the next set of results. Thus, the items count and paging information (i.e first page, current page, next page, previous page, and last page) will be determined automatically as long as you move through pages.

If unchecked, it will be your URL to be executed to get the next page results. In this last scenario you likely want to provide a dynamic URL using builtin tokens.

Example

  • With server-side paging enabled using @odata.nextLink:

    /me/messages?$top={itemsCountPerPage}
    or
    /me/messages?$top=2
    

    Here, the $skip token will be provided automatically in the @odata.nextLink so you don't have to provide it in the URL.

  • Without server-side paging enabled using $top and $skip tokens:

    <your_sharepoint_site_url>/_api/lists?$top={itemsCountPerPage}&$skip={startRow}
    

    If you want to control the paging by yourself, you will have to provide a $skip value manually using builtin tokens. You can use the {itemsCountPerPage} and {startRow} tokens where {startRow} corresponds to the number or items per page * the current page number (start from 0) and {itemsCountPerPage} to the number of items per page configured in the property pane. The URL and the items count will be resolved dynamically based on these token values as long as you move through pages. Because we can't determine the total number of items, in some cases, the last page could be empty. It happens for example when the 'total items count'/'items count per page' is even (i.e. exact same number of items for each page).

Static paging

If performance is not an issue (i.e for a small ammount of data), you can also set a static paging on your data based on a results array. In this case, you will have to provide the response field to use as the array of items to get the total items count. Then, in the common paging settings, configure the desired number items per page to generate pages dynamically.

"OData paging

If you use static paging, don't forget to add a fixed count in your url /me/messages?$top=10 instead of /me/messages?$top={itemsCountPerPage}. Otherwise, you will get only one page every time.