# How to Access Business Central APIs Using App Registration and Postman

Learn how to connect to Microsoft Dynamics 365 Business Central APIs using Microsoft Entra App Registration and OAuth 2.0. A step-by-step tutorial to authenticate with Postman and retrieve customer data.

Author: Mohamed El Omary
Published: 2026-11-01T15:48:12.071Z
Updated: 2026-11-04T14:07:11.932Z
Canonical: https://elomary.com/blog/business-central-api-app-registration-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](https://portal.azure.com/) and sign in with your Microsoft account.

Once you're signed in:

1. Use the **search bar** at the top of the Azure Portal.
2. Search for **App registrations**.
3. 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.

![Screenshot](/api/blog/images/260b28af-8891-46f5-a37c-24189e667c13.png)



*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.

![Screenshot](/api/blog/images/e3d554e1-a710-451e-9697-d97ab853f44f.png)



*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.

![Screenshot](/api/blog/images/3b09775a-81e1-442a-898f-a70e32ebff0f.png)



*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.

![Screenshot](/api/blog/images/26e10bd8-0845-4fe0-8d8c-1ba4a04c0114.png)

*Figure 4: Navigating to API permissions in Microsoft Azure.*

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

![Screenshot](/api/blog/images/c845ecd0-28aa-4e80-97bc-22c3742521c8.png)



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

Under **Microsoft APIs**, select **Dynamics 365 Business Central**.

![Screenshot](/api/blog/images/aef4dae3-e692-4ef4-8445-8352bb06e836.png)



*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**.


![Screenshot](/api/blog/images/b7c98c19-3ca5-431d-9f0d-fb040c90dc40.png)




*Figure 7: Selecting Business Central application permissions.*

### Grant Administrator Consent

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.

![Screenshot](/api/blog/images/29ebb112-358a-4c25-b62e-a678d8cfa286.png)


*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.

1. Click the **Search** icon in the top-right corner.
2. Search for `Microsoft Entra Applications`.
3. Select **Microsoft Entra Applications** from the results.


![Screenshot](/api/blog/images/8ab6949d-bbaf-4410-879d-3cff06748f8a.png)

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

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

![Screenshot](/api/blog/images/935c156f-248f-47cc-bbac-a8168de5e8b3.png)


*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](https://portal.azure.com/), 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.

![Screenshot](/api/blog/images/74e63e5e-beff-494d-941e-88e24aacee83.png)

*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.

![Screenshot](/api/blog/images/424eb0a5-f80b-4e7a-affb-40bdfd8bc663.png)


![Screenshot](/api/blog/images/c2ebcf86-5cf5-4926-9e21-8ad8b90c2a29.png)


*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.

### 4.4 Grant Consent

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."**

![Screenshot](/api/blog/images/fe189ee1-39ac-4b4b-bf11-fd1430adb2e6.png)

![Screenshot](/api/blog/images/0d09a909-3edb-4fa0-93bd-3fd64987b7e3.png)


*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](https://portal.azure.com/) 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**.

![Screenshot](/api/blog/images/299281d7-c77a-454d-867b-839843c2a448.png)

*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.

![Screenshot](/api/blog/images/76497a37-26d6-442d-b3d4-7659145cc079.png)


*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.

![Screenshot](/api/blog/images/8ecf95ee-5253-4e2f-8b28-fc4b9af4dc07.png)

*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:

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

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

![Screenshot](/api/blog/images/ad70a8d3-a201-406a-83a3-e2fe5f8a548b.png)

*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:

```text
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.

![Screenshot](/api/blog/images/a2867088-74bc-456d-9fc5-4fc861b07b6c.png)


*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.

![Screenshot](/api/blog/images/75dda624-e5cd-461e-b578-788c26d4ba48.png)


*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.

![Screenshot](/api/blog/images/634607c9-aaab-4961-a69d-d2e52d891ff2.png)


*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:

```http
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**.

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

![Screenshot](/api/blog/images/c01fefa5-22f4-429a-8423-a529ff8ddef0.png)

*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.

![Screenshot](/api/blog/images/1ce929f4-5f9f-4312-b396-b4f94e8abc07.png)

*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**.

![Screenshot](/api/blog/images/2be46cce-01ab-4873-82f6-cf1c9f457931.png)

*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

```http
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

```json
{
  "@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:

1. App registration in Microsoft Entra ID  
2. API permissions and consent  
3. Registration inside Business Central  
4. Client secret creation  
5. OAuth 2.0 authentication in Postman  
6. 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.