Skip to main content

Calling the WorkPoint API from Power Automate Flows

  • Updated
  • Reading time: —

Article published on the 10th of February, 2026.

1. Introduction

WorkPoint provides a diverse and practical API for many operations in a WorkPoint 365 solution.

On this page, you can consent to the WorkPoint 365 API, as well as find a swagger with a list of available endpoints, as well as functionality to try them out on your own solution (don't forget to select the correct API version in the drop down, then click "Swagger". "NewPlatform" is for WorkPoint 365 Version 4).

In this article, we will go through an example of how WorkPoint's API can be used inside a Power Automate flow using the Active Directory OAuth framework.

For demonstration purposes, we have set up a WorkPoint solution with a Projects module, as well as an unrelated SharePoint site. This SharePoint site will simulate an external system in which we will create a Project item, which will then trigger a Power Automate flow in which we will call the WorkPoint API and create the same project entity in the WorkPoint solution.

This demonstration will go through the following points:

  • Setting up an app registration and giving it permissions to call the WorkPoint API
  • Setting up a demonstration flow
  • Using the flow to create a new entity in a business module in a WorkPoint solution

NOTE: Later in the demonstration setup, we are pasting the app registration secret directly into the HTTP action’s authentication fields. This exposes the secret to anyone with edit permissions on the flow.

In a production environment, you should instead store the secret in Azure Key Vault and retrieve it securely at run time. You can read more about Azure Key Vault here.

Additionally, for production scenarios you should consider enabling Secure inputs and Secure outputs on the HTTP action. These settings ensure that sensitive values - such as tokens, secrets, or API responses - are hidden from run history, preventing them from being exposed to users who can view flow runs. Read more about that here.

The following diagram illustrates the setup we are going to configure in this article:

2. App registration

In this section, we will set up an app registration in Microsoft Entra and grant it application permissions to call the WorkPoint API. Granting application permissions means the app can call the WorkPoint API using its own identity. In other words, the app authenticates with its own permissions and can access the API without any user being involved.

We begin in Microsoft Entra:

  1. In Microsoft Entra we click "App registrations" in the left side panel.
  2. On the App registrations page, we click the "New registration" button.
  1. For the app registration's name, we provide something which enables us to find it again later.
  2. In this demonstration, under "Supported account types", we select a "Single tenant" option.
  3. We then click the "Register" button to create the app registration.

This creates the app registration and opens its configuration page:

At this point, we want to take note of two important IDs, which we want to note down; the app registration's Application (client) ID, and the Directory (tenant) ID. Both of these values can be found on the Overview page, and in our instance, the values are:

  • Client ID: ba212251-bdb5-4c21-b021-************
  • Tenant ID: f00789d0-2c63-4b0a-8c10-************

Next, we need to grant the app registration permissions to call the WorkPoint API:

  1. On the app registration configuration page, we click "API permissions" in the left side menu.
  2. On the API permissions page, we click "Add a permission".
  1. On the "Request API permissions" panel, we switch to "APIs my organization uses" and search for "WorkPoint365".
  2. In the list of results, we click the "WorkPoint365.WebAPI" option.
  1. Next, we select the "Application permissions" option.
  1. In the "Select permissions" section, we check the "ApplicationAccess" option.
  2. We then click "Add permissions".

The permission has now been added to the App Registration. Next, we need to grant admin consent for them to be used:

  1. In the configured permissions section, we click "Grant admin consent for <Tenant>" button.
  1. In the pop-up dialogue, we click "Yes" to confirm.

The status of the permissions in the "Configured permissions" list should now show "Granted for <Tenant>":

Next, we will create a secret for our app registration:

  1. In the left side menu, we click "Certificates & secret".
  2. We then click "New client secret".
  1. In the right side panel, we give the new secret a descriptive name and click the "Add" button.
  1. Once the secret has been generated, we click the "Copy to clipboard" button for the secret Value and store it along with the other information we need later.

At this point, we should have the following information noted down:

  • Tenant ID: f00789d0-2c63-4b0a-8c10-************
  • App registration Client ID: ba212251-bdb5-4c21-b021-************
  • App registration secret: ZOG8Q~Cm.wfTT5V2r*************************

3. WorkPoint WebAPI Application ID

The last information we need in order to start calling the WorkPoint API from a Power Automate flow using OAuth is the WorkPoint WebAPI's Application ID, which we will use as Audience.

We can find the WorkPoint WebAPI Application ID by looking it up under "Enterprise apps":

  1. In the left side menu of Microsoft Entra admin center, we click "Enterprise apps".
  2. In the Search box, we search for "WorkPoint365.WebAPI".
  3. We can then copy the Application ID. We then store this together with the other information we noted down earlier.

We should now have the following information noted down:

  • Tenant ID: f00789d0-2c63-4b0a-8c10-************
  • App registration Client ID: ba212251-bdb5-4c21-b021-************
  • App registration secret: ZOG8Q~Cm.wfTT5V2r***********************
  • WorkPoint365.WebAPI Application ID: e5b0fac6-320d-4ff4-9c53-************

4. Power Automate

Now that we have all the information we need to call the WorkPoint API using OAuth in Power Automate, we can start making our flow.

To start, we have already created a flow with a "When an item is created" SharePoint trigger, as well as a Parse JSON step:

  1. For the trigger, we point to the SharePoint site acting as our external system, as well as the Projects list on there. This is where we will simulate creating a project in an external system, and which will then trigger the next steps of this flow to run.
  2. In the Parse JSON step, we parse the output from the trigger, essentially allowing us to easily work with the data from the item that triggered the flow.

Next, we add a HTTP step:

  1. In the URI field, we paste the URI to the endpoint of the WorkPoint API that we want to call. In this instance, we are going to create an entity inside a business module, and create a site using the Asynchronous site creation behaviour.
  2. In the Method field, we select POST.
  3. In the Headers section, we configure the Accept and Content-type headers, and we also need to remember the WorkPoint365Url header specifying the root site of the WorkPoint site on which we want to create an entity with this endpoint.
  4. In the Body field, we insert the information for the new project we want to create on the WorkPoint solution. In this instance, we get the title from the item which triggered the flow to run, but we hard-code the Parent for the project to be the "WorkPoint A/S" company we already have in the WorkPoint solution.

Scrolling a bit down on the HTTP step, we can configure authentication:

  1. In the Authentication type field, we select Active Directory OAuth.
  2. In the Tenant field, we paste in the Tenant ID we noted down earlier.
  3. In the Audience field, we paste in the WorkPoint API enterprise app Application ID we noted down earlier.
  4. In the Client ID field, we paste in the Client ID of the app registration we created earlier.
  5. In the Credential type field, we select "Secret", and in the Secret field, we paste the secret we generated for the app registration earlier.

We can now save the flow and test it out.

Since this is a demo, we paste the secret directly here.

Important: For production, store the secret in Azure Key Vault and enable Secure inputs/outputs on this action. See the note in the introduction.

5. Testing the setup

Now that we have created our app registration, given it permissions to communicate with the WorkPoint API, and created our Power Automate flow, we can test the system out.

In our SharePoint site acting as our external system, we can now create a project in the Projects list:

  1. In the Projects list on the SharePoint site, we create a new item called "Project Gold".
  2. We then click the "Save" button.

After a couple of seconds, the Power Automate picks up on the event in the SharePoint list, and runs:

After a couple more seconds, it succeeds:

If we look in our WorkPoint solution, inside our Projects business module, we can see the entity has been created using the WorkPoint API:

6. Troubleshooting

Symptom Likely cause Fix
400 Bad Request from WorkPoint API
 JSON body is malformed, missing required fields, or property names don’t match the API contract.
 Validate the JSON with a formatter, compare it with the Swagger definition for the endpoint, and ensure required fields (e.g. Title, Parent, Template, etc.) are present and correctly spelled.
401 Unauthorized from HTTP action Incorrect Client ID / secret / Tenant ID. Verify app registration details and re-paste them into the HTTP action.
403 Forbidden
 App registration missing Application access or admin consent.
 Check API permissions in Entra and ensure admin consent is granted.
404 Not Found from WorkPoint API The endpoint URL is incorrect or the API version doesn’t exist.
 Double-check the URI against the Swagger page for the correct API version, and make sure WorkPoint365Url header points to the correct WorkPoint root site.
Invalid audience
 Wrong Application ID used in Audience field.
 Make sure you’re using the WorkPoint365.WebAPI enterprise app’s Application ID.
Flow runs but entity not created
 Wrong WorkPoint365Url or request body.
 Verify the header value and required fields for the endpoint in the Swagger UI.
Flow used to work but suddenly returns 401 or AADSTS errors
 Client secret or certificate has expired.
 Check the app registration’s Certificates & secrets in Entra. Create a new secret, update the HTTP action (or Key Vault secret), and save the flow.
Flow fails in Parse JSON step before calling HTTP
 The schema doesn’t match the current SharePoint item structure.
 Regenerate the Parse JSON schema using a fresh sample from the trigger output, or remove unused fields from the schema.
Flow never starts when a new item is created
 Trigger is pointing at the wrong site/list, or the connection user no longer has access.
 Verify the trigger configuration (site and list), and check that the connection user still has permission to the SharePoint site and list. Re-authenticate the SharePoint connection if needed.
Was this article helpful?
0 out of 0 found this helpful

Related articles

Comments

0 comments

Article is closed for comments.