Microsoft Dynamics 365 and Dataverse already provide a comprehensive REST API. So why would an organisation build another business API in front of something that already has one?

For internal integrations, the Dataverse Web API is often exactly the right choice. But when customers, partners, suppliers, or externally operated systems need to consume Dynamics 365 data, exposing Dataverse directly can create unnecessary coupling between an external integration and the internal Dynamics environment.

A custom business API provides an alternative. Instead of allowing consumers to understand and query the Dynamics 365 data model directly, the organisation publishes a deliberately designed contract such as:

GET /customers/{id}
GET /applications/{id}/status
POST /applications

The implementation translates these business operations into the appropriate Dataverse queries and updates.

Why not just expose the Dataverse API?

Identity and tenant boundaries

External users accessing Dataverse interactively generally need to exist as Microsoft Entra B2B guest users in the provider tenant, with the appropriate Dataverse permissions and licensing. Microsoft also provides environment-level controls allowing administrators to completely restrict Dataverse access by guest users.

An important exception applies to system-to-system integration. Dataverse supports application users backed by Microsoft Entra service principals, so it is not technically correct to say that every consuming system must have a conventional or guest user account. However, allowing an externally controlled integration identity to communicate directly with Dataverse still couples the consumer to the provider’s identity, environment and Dataverse authorisation configuration.

With a custom API, callers instead authenticate to a deliberately exposed API using OAuth 2.0 client credentials or another supported mechanism. The API itself owns the trusted connection to Dataverse.

Dataverse security may not represent external authorisation

Dataverse uses security roles, business units, ownership, teams, privileges and access levels to decide which records users can access.

That model is normally designed around internal business processes.

An external application might need a very different rule, e.g.:

Partner A can see applications submitted by organisations associated with Partner A, but only selected information after the application reaches a particular status.

Trying to reproduce that rule entirely through Dataverse record ownership and security roles can significantly complicate the internal Dynamics security model.

A custom API separates the two concerns. Dynamics security continues protecting the operational system while the API applies authorisation rules appropriate to external consumers.

The internal schema becomes an external contract

Direct API access also exposes details of the Dataverse implementation: table names, relationship structures, choice values, column names and potentially information that was never intended for external consumption.

Column-level security can restrict access to sensitive Dataverse columns, but using it extensively simply to construct an external API boundary increases administration and testing complexity.

More importantly, once external developers build against your internal schema, changing that schema becomes harder.

A business API provides an abstraction layer. An internal column such as new_assessmentoutcome might simply become:

{
  "status": "Approved"
}

Dynamics can subsequently change without necessarily breaking the external contract.

What infrastructure is required?

A typical Microsoft implementation contains four main layers.

1. Azure API Management (APIM) provides the externally accessible gateway. It can validate tokens, enforce quotas and rate limits, apply policies, provide monitoring and expose independently versioned APIs. Microsoft specifically positions APIM for publishing APIs to developers, partners and employees and provides policies covering areas including transformation and throttling.
2. Microsoft Entra ID application registrations provide identities. Normally there is an app registration representing the published API, consumer/client registrations where appropriate, and a separate managed identity or application identity used by the backend to access Dataverse.
3. An API implementation is still required behind APIM. For a relatively small interface, this might be an Azure Function or ASP.NET Core application hosted in Azure App Service or Azure Logic Apps. This layer implements validation, business authorisation, and transformations between the external contract and Dataverse.
4. Finally, use separate Development, Test/UAT and Production environments. Each should connect only to its corresponding Dataverse environment and use separate identities, configuration and secrets. Never share production credentials with development.

What might it cost?

Consider an API containing approximately 10 GET/POST operations, each with up to 20 request or response parameters, processing only 100 transactions per day, or roughly 3,000 API requests per month.

At that volume, transaction processing itself is negligible. The cost drivers are architecture, security and support rather than throughput.

As a planning estimate, a professional implementation would typically require approximately:

At an indicative Australian consulting rate of A$1,400–A$2,000 per day, that translates to approximately A$30,000–A$78,000 for implementation. This is a planning estimate rather than Microsoft pricing, and complex business authorisation, integration testing or partner onboarding can push the figure higher.

Operating costs can be surprisingly small if the architecture uses serverless/consumption services. Third-party 2026 pricing references report APIM Consumption as having no fixed base charge and approximately US$3.50 per million calls after the included allowance. At 3,000 calls per month, API transaction volume itself therefore contributes nothing material.

Dedicated APIM changes the economics dramatically. Microsoft’s current published pricing lists Basic v2 at approximately US$150/month, Standard v2 at US$700/month, and Premium v2 around US$2,801/month, before regional and contractual adjustments. Running separate dedicated APIM instances for three environments can therefore become far more expensive than the API workload itself.

Azure Function/App Service, Application Insights/Log Analytics and networking may add further charges. Exact Australian costs should consequently be calculated in the Azure Pricing Calculator for the chosen region and architecture before implementation.

Dataverse requests also remain subject to Microsoft Power Platform request allocations and service-protection limits. Dataverse CRUD operations through REST count as Power Platform requests, including operations originating from applications. At only 100 business transactions per day this is unlikely to be the primary capacity concern, although one external transaction may generate multiple Dataverse operations.

Pros and cons

Advantages

• External consumers receive a stable, business-oriented API rather than the internal Dynamics schema.
• External authorisation can be independent of Dynamics record ownership.
• APIM provides centralised authentication, throttling, quotas, monitoring and API versioning.
• Sensitive tables and columns never need to be externally discoverable.
• Dynamics schema changes can be isolated from consumers.
• The same API can later aggregate Dynamics data with other systems.

Disadvantages and limitations

• An additional application must be developed, tested, monitored and supported.
• Every new external operation may require API development rather than simply exposing another Dataverse query.
• Mapping introduces another potential source of defects.
• API versioning becomes a formal responsibility once consumers depend on the contract.
• APIM dedicated tiers can be expensive relative to a low-volume workload.
• Large queries, bulk data synchronisation, and high-volume extraction may be better served by another integration pattern.
• Dataverse API limits still apply behind the custom API.
• The additional API layer adds a small amount of latency and another component that can fail.

The key architectural decision

• An additional application must be developed, tested, monitored and supported.
• Every new external operation may require API development rather than simply exposing another Dataverse query.
• Mapping introduces another potential source of defects.
• API versioning becomes a formal responsibility once consumers depend on the contract.
• APIM dedicated tiers can be expensive relative to a low-volume workload.
• Large queries, bulk data synchronisation, and high-volume extraction may be better served by another integration pattern.
• Dataverse API limits still apply behind the custom API.
• The additional API layer adds a small amount of latency and another component that can fail.

A custom API should not be built simply because Dataverse has an API that looks too technical. For trusted internal applications, direct Dataverse integration is often simpler and entirely appropriate.

The pattern becomes compelling when the boundary is also an organisational trust boundary.

When external consumers should understand your business capabilities, but should not understand your Dynamics 365 security model or internal implementation, Azure API Management plus a purpose-built business API gives you a controlled contract that can remain stable even as the Dynamics solution behind it evolves.

Technomancy experience

We have built API layers and integrations between Dynamics and external platforms for different use cases. Our customers’ experience shows this pattern is valid and meets business needs well. Contact us to discuss the initial assessment of the suitability of this or an alternative approach for your use case.