How to Access Business Central APIs Using App Registration and Postman

Microsoft Dynamics 365 Business Central provides REST APIs that allow external applications to access and interact with business data.

Whether you're integrating a CRM, an e-commerce platform, or another third-party system, you can use these APIs to retrieve customers, vendors, items, sales orders, and much more.

In this tutorial, we'll configure Microsoft Entra App Registration, authenticate using OAuth 2.0, and make our first API requests using Postman.

By the end, we'll be able to retrieve customer data from Business Central without using a user's credentials.

Prerequisites

Before getting started, you'll need:

Access to a Business Central Online environment (preferably a sandbox).
Access to Microsoft Entra ID with permission to register applications.
Administrator assistance to grant API consent and configure application permissions.
Postman installed on your computer.

We'll use the standard Business Central API v2.0, so there's no need to develop or publish an AL extension.

Step 1: Open App Registrations in Microsoft Azure

First, navigate to the Microsoft Azure Portal and sign in with your Microsoft account.

Once you're signed in:

Use the search bar at the top of the Azure Portal.
Search for App registrations.
Select App registrations from the search results.

This is where we'll create the application that will allow us to authenticate and access Microsoft Dynamics 365 Business Central APIs.

Figure 1: Searching for App registrations in Microsoft Azure Portal.

Next, click App registrations, then select New registration to create our application.

Step 2: Create a New App Registration

Once you're on the App registrations page, click + New registration to create a new application.

Figure 2: Creating a new application registration in Microsoft Azure.

On the Register an application page, configure the following:

Name: API Integration Demo (you can choose any name).
Supported account types: Select Accounts in this organizational directory only (Single tenant).
Redirect URI (optional): For our OAuth 2.0 Client Credentials flow, a redirect URI is not required, so you can leave this field empty.

Important: We'll use this Business Central redirect URI during the application consent process. It allows Microsoft Entra ID to redirect the authorization response back to Business Central when granting consent through its web client.

Figure 3: Configuring the application name, supported account types, and optional redirect URI.

Once everything is configured, click Register.

After registration, Microsoft Azure will redirect you to the application's Overview page, where you'll find the Application (client) ID and Directory (tenant) ID.

We'll need these values later when configuring authentication in Postman.

Step 3: Configure API Permissions

Now that our application is registered, we need to configure the permissions that will allow it to access Microsoft Dynamics 365 Business Central APIs.

From the application's Overview page, navigate to API permissions in the left-hand menu.

Figure 4: Navigating to API permissions in Microsoft Azure.

Click + Add a permission to open the API selection window.

Figure 5: Adding a new API permission to our application.

Under Microsoft APIs, select Dynamics 365 Business Central.

Figure 6: Selecting Dynamics 365 Business Central from the available Microsoft APIs.

Next, choose Application permissions. This allows our application to access Business Central without requiring a user to sign in interactively.

For our demonstration, we're configuring the following permissions:

API.ReadWrite.All: Allows the application to access Business Central APIs and web services. This is the permission we need to retrieve customer data.
Automation.ReadWrite.All: Provides access to Business Central Automation APIs, which are typically used for administrative automation tasks.
app_access: Allows access according to the application's permissions defined in Business Central.

Note: For simply retrieving customers through the standard Business Central API, API.ReadWrite.All is sufficient at the Microsoft Entra API permission level. The other permissions are shown as part of our demonstration configuration and are not required for this specific request. In production, grant only the permissions your integration needs.

Select the appropriate permissions and click Add permissions.

Figure 7: Selecting Business Central application permissions.

After adding the permissions, you'll notice that their status may indicate Not granted.

To authorize the application, click Grant admin consent for [Your Tenant Name].

A confirmation dialog will appear. Click Yes to approve the requested permissions.

Figure 8: Granting administrator consent for the application permissions.

Once consent is granted successfully, the permission status should indicate that consent has been granted for your organization.

Important: Granting administrator consent in Microsoft Entra ID does not automatically give the application access to all Business Central data. We'll also need to register the application inside Business Central and assign the appropriate permission sets.

With our API permissions configured, we're ready to move on to the next step: generating a client secret for authentication.

Step 4: Register the Application in Business Central

Now that we've configured the API permissions in Microsoft Azure, we need to register our application inside Microsoft Dynamics 365 Business Central.

This step is important because granting permissions in Microsoft Entra ID alone doesn't automatically give our application access to Business Central data.

4.1 Open Microsoft Entra Applications

First, open your Business Central environment.

Click the Search icon in the top-right corner.
Search for Microsoft Entra Applications.
Select Microsoft Entra Applications from the results.

Figure 9: Searching for Microsoft Entra Applications in Business Central.

Once the page opens, click + New to register our application.

Figure 10: Creating a new Microsoft Entra Application in Business Central.

4.2 Configure the Application

We now need the Application (client) ID from the app registration we created earlier.

Return to the Microsoft Azure Portal, open App registrations, and select our API Integration Demo application.

From the Overview page, copy the Application (client) ID and paste it into the Client ID field in Business Central.

Figure 11: Copying the Application (client) ID from Microsoft Azure into Business Central.

Next, configure the remaining fields:

Description: API Integration Demo
State: Set to Enabled.

4.3 Assign Permission Sets

Next, we need to specify what our application is allowed to access inside Business Central.

Scroll down to the User Permission Sets section and click + New Line.

In the Permission Set field, click the lookup button (...) to browse the available permission sets.

For our demonstration, we're assigning the following permission sets:

D365 BUS PREMIUM: Provides broad access to Business Central business functionality.
D365 AUTOMATION: Provides permissions for Business Central automation scenarios.

Select the permission sets and confirm your selection.

Figure 12: Permission sets assigned to our API Integration Demo application.

Important: These permission sets are used for demonstration purposes. For production integrations, it's recommended to assign only the permissions required by your application.

Now that our application is enabled and the permission sets are assigned, we need to grant consent.

From the Microsoft Entra Application Card, click Grant Consent.

A Microsoft sign-in window will open, displaying the permissions requested by our application.

Review the permissions carefully and click Accept to continue.

If everything is configured correctly, Business Central will display the following confirmation message:

"Consent was given successfully."

Figure 13: Granting consent to our application and confirming that consent was given successfully.

That's it! Our application is now registered, enabled, and authorized to access Business Central according to its assigned permissions.

In the next step, we'll generate our client secret in Microsoft Azure, configure OAuth 2.0 authentication in Postman, and use our application credentials to request an access token.

Step 5: Generate a Client Secret in Microsoft Azure

Now that our application is registered and authorized in Business Central, we need to generate a Client Secret.

The Client Secret acts as a credential that allows our application to authenticate with Microsoft Entra ID and request an access token.

5.1 Create a Client Secret

Return to the Microsoft Azure Portal and open our API Integration Demo application.

From the left-hand menu, navigate to Certificates & secrets.

Under the Client secrets tab, click + New client secret.

Figure 14: Navigating to Certificates & secrets and creating a new client secret.

A new panel will appear. Configure the following:

Description: PostmanSecretToken
Expires: 180 days (6 months)

Click Add to generate the secret.

Figure 15: Configuring the client secret description and expiration period.

5.2 Copy the Client Secret Value

Once the Client Secret is created, it will appear in the Client secrets list.

You'll notice two important fields:

Value: The actual secret we'll use to authenticate our application.
Secret ID: A unique identifier for the secret. This is not the value we need for authentication.

Copy the Value and store it securely. We'll use it later when configuring Postman.

Figure 16: Copying the newly generated client secret value.

Important: The Client Secret Value is displayed only once. Make sure to copy it before leaving the page. Never expose client secrets in source code, screenshots, or public repositories.

Step 6: Configure OAuth 2.0 Authentication in Postman

Now comes the interesting part! Let's use Postman to authenticate our application and generate an access token.

For this demonstration, we'll use the OAuth 2.0 Client Credentials flow, which allows applications to authenticate without requiring a user to sign in interactively.

6.1 Get the OAuth 2.0 Token Endpoint

First, return to our application in the Azure Portal.

From the Overview page, click Endpoints.

A panel will appear containing several authentication endpoints.

Locate and copy the OAuth 2.0 token endpoint (v2).

The URL follows this structure:

https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token

Replace {tenantId} with your Microsoft Entra Directory (Tenant) ID.

Figure 17: Copying the OAuth 2.0 token endpoint (v2) from Microsoft Azure.

6.2 Configure Postman Authorization

Open Postman and create a new HTTP request.

Navigate to the Authorization tab and select OAuth 2.0 as the authorization type.

Under Configure New Token, enter the following information:

Setting	Value
Token Name	`API Integration Demo`
Grant Type	`Client Credentials`
Access Token URL	`https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token`
Client ID	Application (client) ID from Azure
Client Secret	Client Secret Value generated in Step 5
Scope	`https://api.businesscentral.dynamics.com/.default`
Client Authentication	`Send as Basic Auth header`

The Scope is particularly important:

https://api.businesscentral.dynamics.com/.default

The .default scope tells Microsoft Entra ID to issue a token containing the approved application permissions for the Business Central API resource.

Figure 18: Configuring OAuth 2.0 Client Credentials authentication in Postman.

Note: Make sure you're using the Client Secret Value, not the Secret ID. Also, the OAuth 2.0 token endpoint must match the tenant where your application is registered.

6.3 Generate an Access Token

Once all the required fields are configured, scroll down and click Get New Access Token.

Postman will send an authentication request to Microsoft Entra ID using our application credentials.

Figure 19: Requesting a new OAuth 2.0 access token using Postman.

If everything is configured correctly, Postman will display the following message:

"Authentication complete"

This confirms that Microsoft Entra ID has successfully authenticated our application.

Figure 20: Successful OAuth 2.0 authentication in Postman.

Click Proceed, and use the generated token for your request if Postman prompts you to select it.

Postman can now attach the access token to API requests using the following HTTP header:

Authorization: Bearer {accessToken}

We've successfully authenticated our application using OAuth 2.0!

Keep in mind that obtaining a token confirms authentication, but doesn't yet prove that the application can access Business Central data. That will be verified by our first API request.

In the next step, we'll use our access token to make a GET request to the Business Central API and retrieve company and customer information in JSON format.

Step 7: Test the Web Service in Postman

Now that our application is authenticated and we already have an access token in Postman, we can test the connection by calling a published Business Central web service.

In this example, we'll test a customer web service and verify that Business Central returns data successfully.

7.1 Open the Web Services Page in Business Central

Go back to Business Central.

Click the Search icon in the top-right corner.
Search for Web Services.
Select Web Services from the results.

Figure 21: Searching for the Web Services page in Business Central.

7.2 Copy the OData V4 URL

On the Web Services page, locate the published web service you want to test.

In our example, we’re using the service:

Service Name: workflowCustomers

Copy the OData V4 URL of the service.

Figure 22: Copying the OData V4 URL from the published Business Central web service.

Note: Business Central recommends using API pages instead of OData pages for better performance and stability. However, for this demonstration, we’re testing a published OData V4 web service.

7.3 Paste the URL into Postman and Send the Request

Open Postman and create or reuse a GET request.

Paste the copied OData V4 URL into the request URL field.

Make sure the Authorization tab is still configured with OAuth 2.0, and that the access token is already attached to the request.

Then click Send.

Figure 23: Testing the Business Central web service by sending a GET request from Postman.

7.4 Verify the Response

If everything is configured correctly, Postman should return:

HTTP Status: 200 OK
A JSON response body containing customer data

In our example, the response includes records such as:

number
name
other customer-related fields returned by the web service

A successful response confirms that:

the Azure App Registration is configured correctly
the client credentials are valid
the OAuth 2.0 token was generated successfully
the Business Central permissions are correctly assigned
the published web service is accessible

Example Request

GET https://api.businesscentral.dynamics.com/v2.0/{tenantId}/{environment}/ODataV4/Company('CRONUS%20USA%2C%20Inc.')/workflowCustomers
Authorization: Bearer {accessToken}
Accept: application/json

Example Response

{
  "@odata.context": "https://api.businesscentral.dynamics.com/v2.0/.../$metadata#Company('CRONUS USA, Inc.')/workflowCustomers",
  "value": [
    {
      "id": "8e704376-f25e-f111-8e24-7ced8d25bfd9",
      "number": "10000",
      "name": "Adatum Corporation"
    }
  ]
}

Important: Your response may contain more fields depending on the web service definition. If you're publishing a page, query, or API page, the returned JSON structure may vary.

Conclusion of the Test

At this point, we’ve successfully tested our Business Central web service from Postman.

This confirms that the full flow is working:

App registration in Microsoft Entra ID
API permissions and consent
Registration inside Business Central
Client secret creation
OAuth 2.0 authentication in Postman
Successful API/web service test

Security note: All client secrets, access tokens, and API keys shown in this article are used exclusively for this demo and will be revoked or deleted afterward. Always keep your own credentials private.