I made some additional tweaks, so we need to only change few variables when targeting a newer environment later, when creating a duplicate environment in Postman. Your environment should now look something like below. Scope: The scope would be in the following format This is required for the Client Credentials flow only.
TenantId: The Id of the Azure tenant in which your Dynamics365 org and the app registration exist.ĬlientSecret :- Generate a secret for your application as shown below. TokenUrl:- The url to the Azure token endpoint by clicking the Endpoints in the previous image, as shown below.ĬlientId:- This is the Application (client) ID in the Overview of the App RegistrationĬallbackUrl:- Since we are using the desktop client we can just use the recommended URI provided by Azure in our app registration as shown below. You could get the auth url by clicking the Endpoints authUrl:- The url to the Azure Authorization endpoint if using the authorization code flow for generating the token.version:- Version of the Web API you want to target.Your environment should have the following variables Generating Access Token using Client Credentials.Generating Access Token using Authorization Code flow (Microsoft Application ID).Generating Access Token using Authorization Code flow.Configure Authorization on the Collection.In this post I will be showing the steps to the following tasks.
My favorite tool to quickly perform testing is using the Postman desktop client.
There are tools which we could leverage to accomplish this task Ex:- Postman, Soap UI etc. With Dynamics 365 and introduction of Web API there are now better ways to quickly test CRUD operations.
Traditionally I would have done this either using a console application or within the web client. Recently when working on Dynamics 365 I had to quickly test a couple of actions and make sure they are working as expected.