The process of building custom applications and tools that interact with Microsoft SharePoint, including SharePoint Online in Microsoft 365.
This behavior is common because the local workbench (gulp serve) uses a more permissive authentication flow that does not fully enforce SharePoint Online’s token service checks. In that mode, Azure AD can often issue tokens directly based on the developer’s sign-in context.
To troubleshoot it, you could try to follow these steps:
In your API’s Azure AD app registration
Go to Expose an API and ensure an Application ID URI is defined (typically api://<client-id-of-this-app> or a custom URI such as https://yourtenant.onmicrosoft.com/yourapi).
Expose the required scopes (for example: access_as_user, user_impersonation, etc.).
Ensure user or admin consent is granted for those scopes if required.
Update package-solution.json
Add or correct the webApiPermissionRequests array under the solution node:
"webApiPermissionRequests": [
{
"resource": "<Exact Display Name of your API app registration in Azure AD>",
"scope": "<Scope name you exposed, e.g. user_impersonation or access_as_user>"
}
]
You can refer via this link.
Re-package and re-deploy
gulp bundle --ship
gulp package-solution --ship
Upload the new .sppkg file to the tenant app catalog (and deploy it if you are using tenant-wide deployment).
Approve the permission in SharePoint Admin Center
Go to SharePoint Admin Center > Advanced > API access
You should see a pending request for your API app name and scope
Select Approve (permission propagation may take a few minutes)
I hope this helps.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.