Service Endpoints, Authentication, and Integration Apps in Dynamics 365 for Operations

This blog will explain the different Integration services, integration scenarios and types, integration applications, and user authentication available to Microsoft Dynamics 365 for Operations. It will also compare and provides pros and cons for each integration type and application.

List of Services

The following table lists all the service endpoints that were available in Microsoft Dynamics AX 2012 and the new service endpoints that have been introduced in Dynamics 365 for Operations. One thing to note is that the SOAP-based services in Dynamics 365 for Operations remain the same as they were in Dynamics AX 2012.

Service endpoint Dynamics 365 for Operations
Document Services (AXDs) Data Entities
SOAP-based Metadata Service REST metadata service
SOAP-based Query Service OData 4.0
OData Query Service OData 4.0
SOAP-based Custom Service Yes
JSON-based Custom Service Yes (New)
OData Service Yes (New)
REST Metadata Service Yes (New)

Key Changes in Services

  • All the service groups under the AOT\Service group node are automatically deployed.
  • All services that must be deployed must be part of a service group.

The SOAP endpoint is at https://<host_uri>/soap/Services/<service_group_name>.

Code Example:

The following documentation is from the Dynamics AX 2012 X++ Custom SOAP Services, and it will help you design and write services in Dynamics 365 for Operations:

More Code Examples – We have some sample code examples for consuming custom services at

JSON-based Custom Service

This Dynamics 365 for Operations feature enables X++ classes to be consumed as JSON services. In other words, the return data set is in JSON format. JSON, which stands for JavaScript Object Notation, is a compact, lightweight format that is commonly used communicate data between the client and the server.

In Dynamics 365 for Operations, after the developer has written the services under service groups, the service groups are always deployed on two endpoints:

  • SOAP endpoint (mentioned in the previous section)
  • JSON endpoint

The JSON Endpoint is at: https://<host_uri>/api/Services/<service_group_name>/<service_group_service_name>/<operation_name>.

Code Example:

You can find a Microsoft Office Mix presentation about this topic here.

More Code Examples – We have some sample code examples for consuming Json services at

OData Services

Dynamics 365 for Operations has introduced an OData REST endpoint. This endpoint exposes all the data entities that are marked as IsPublic in the Application Object Tree (AOT). It supports complete CRUD (create, retrieve, update, and delete) functionality that users can use to insert and retrieve data from the system.

Detailed labs for this feature are on the LCS methodology. You can find an Office Mix presentation about OData Services here.

Supported Features from the OData Specification

The following table lists the high-level features that are enabled in Dynamics 365 for Operations OData, per the OData specification.

OData v4 feature Details OData v4 specification reference
CRUD HTTP Verb support for POST, PATCH, PUT, and DELETE
Query options $filter







Server-driven paging The maximum page size that is served is 1,000.
Actions that are bound to entities
Actions that are bound to entity sets
Built-in operators for $filter Equals

Not Equals

Greater Than

Greater Than or Equal

Less Than

Less Than or Equal







Contains option in $filter Implemented as a wildcard character Example: http://host/service/EntitySet?$filter=StringField eq ‘*retail*’
Batch requests
Metadata annotations /data/$metadata has out-of-box annotations.
EnumType support Example of how EnumType is supported in $metadata:

Code Examples – We have some sample code examples for consuming Odata services at

Cross-company Behavior

By default, OData returns only data that belongs to the user’s default company. To see data from outside the user’s default company, specify the ?cross-company=true query option. This option will return data from all companies that the user has access to.

Example: http://[baseURI]/data/FleetCustomers?cross-company=true

To filter by a particular company that isn’t your default company, use the following syntax:
http://[baseURI]/data/FleetCustomers?$filter=dataAreaId eq ‘usrt’&cross-company=true

Validate Methods

The following table summarizes the validate methods that the OData stack calls implicitly on the corresponding data entity.

OData Methods (listed in the order in which they are called)
  1. Clear()
  2. Initvalue()
  3. PropertyInfo.SetValue() for all specified fields in the request
  4. Validatefield()
  5. Defaultrow
  6. Validatewrite()
  7. Write()
  1. Forupdate()
  2. Reread()
  3. Clear()
  4. Initvalue()
  5. PropertyInfo.SetValue() for all specified fields in the request
  6. Validatefield()
  7. Defaultrow()
  8. Validatewrite()
  9. Write()
  1. Forupdate()
  2. Reread()
  3. checkRestrictedDeleteActions()
  4. Validatedelete()
  5. Delete()

REST Metadata Service

This is a new service endpoint that has been introduced in Dynamics 365 for Operations. This is a read-only service. In other words, users can make only GET requests. The main purpose of this endpoint is to provide metadata information for elements. It is an OData implementation.

This endpoint is hosted at http://[baseURI]/Metadata.

Currently, this endpoint provides metadata for the following elements:

  • Labels – This gets labels from the system. They have a dual pair key, language, and ID, so that you can retrieve the value of the label.
    Example: https://[baseURI]/metadata/Labels(Id=’@SVC_ODataLabelFile:Label1′,Language=’en-us’)
  • Data entities – This returns a JSON-formatted list of all the data entities in the system.
    Example: https://[baseURI]/Metadata/DataEntities

We will support more sets of metadata as new scenarios require it.


OData Services, JSON-based Custom Service, and REST Metadata Service support standard OAuth 2.0 authentication. You can read more about OAuth 2.0 here.

Microsoft currently supports Authorization Code Grant flow.

Two kinds of application are supported in Microsoft Azure Active Directory (AAD):

  • Native client application – This flow uses a user name and password for authentication and authorization.
  • Web application (Confidential client) – A confidential client is an application that can keep a client password confidential to the world. The authorization server assigned this client password to the client application. This will be supported post-RTW.

OAuth – Authorization Code Grant Flow

Register a Native Application with AAD

Before any clients can communicate with Dynamics 365 for Operations services, they must be registered in AAD.

These steps will help you register an application with AAD.

Note: These steps don’t have to be completed by all the people in your organization. Only one Azure admin user can add the application and share the client ID with the developers.

Prerequisite: You must have an Azure subscription and admin access to Active Directory.

  1. In a web browser, go to
  2. Enter the user name and password of the user who has access to the Azure subscription. After the credentials are authenticated, Azure Portal opens.
  3. In Azure Portal, in the left navigation pane, click Active Directory.
  4. In the grid, select the Active Directory instance that is being used for Dynamics AX.
  5. On the top toolbar, click Applications.
  6. In the bottom pane, click Add. The Add application wizard starts.
  7. Add a new native client application. Enter information in the wizard as shown in the following screen shots.
  8. Click the check mark button to complete the wizard. After you complete the wizard, the new application page opens.
  9. On the top toolbar, click Configure.
  10. Scroll down until you see the Permissions to other applications section. Click Add Application in this section.
  11. Select Microsoft Dynamics ERP in the list
  12. Click the Complete check button in the right corner of the page.
  13. In the Delegate Permissions list, select all the check boxes. Note: We are working on cleaning up this list.
  14. Make a note of the following two pieces of information:
    1. Client ID – As you scroll toward the top of this page, you will see Client ID displayed.
    2. Redirect URI

After you have these two pieces of information, you’re ready to write your client code.

Integration and Integration Types

Microsoft’s Enterprise Integration Vision

Microsoft BizTalk

  • Logic App adapter – 2016 support for Logic App
  • Call Operations REST/OData
    • Send pipeline with custom behavior to implement AAD authentication
  • Keep using as on premise middleware
  • Can integrate with Operations
    • Enqueue/Dequeue/JobStatus/Ack
    • OData/Rest

Azure Service Bus

  • Asynchronous messaging cloud platform
  • Decoupled communication
  • Reliability
  • Load balance\buffering

Microsoft QuartzAX

A self-hosted solution that can import/export files to/from Operations


  • Easy to configure
  • Easy to use
  • Free


  • Manageability
  • Scalability
  • Error handling and real time alerts
  • Dual scheduling

Microsoft Logic Apps

  • IPaaS
  • Cloud and on premise connectors
  • Light up other Azure services
  • Operations connector available
    • CRUD
    • Execute action
  • Generic HTTP connector
    • Enqueue/Dequeue/JobStatus/Ack
  • Enterprise Integration Pack – B2B workflow
  • Preferred way to interact with recurring job


  • Scalability
  • Manageability
  • Guaranteed delivery
  • Error handling
  • Real time alerts


  • Not free
  • Only available in the cloud

Microsoft Flow

  • No Azure subscription needed
  • Citizen integrators
  • Flow is built on top of Logic Apps
  • They have the same workflow designer
  • Connectors that work in one can also work in the other

Microsoft Flow vs. Logic Apps

For questions on Dynamics 365 for Operations service endpoints, please contact Hitachi Solutions today.