Logic API

Install and host Logic API

Install the Logic API solutions, and agree with your hosting team on the settings that make a published API available to callers.

Logic API has two parts. The solutions you install in Dataverse hold the API definitions and give designers API Studio. The API host is a web application that your organization runs: it reads a published API from Dataverse and answers the calls that apps make. This page covers what you install, and the decisions you make with the team that runs the host.

Logic API works with both editions. With Dynamics 365 CE on-premises, the API host connects to your on-premises organization, using the connection string type your deployment signs users in with (for example Active Directory or internet-facing deployment).

Solutions

Solution	What it adds	Install in
Logic Fabric Base	The foundation shared by all Logic Fabric products.	Every environment, first.
Logic Fabric API Builder	APIs and API versions, the Logic Fabric API Builder app, and publishing.	Every environment that holds or serves an API.
Logic Fabric API Builder Tools	API Studio and the designer commands.	Environments where you design APIs (typically development).

Install the solutions

Import Logic Fabric Base if it isn’t installed yet.
Import Logic Fabric API Builder.
In design environments, import Logic Fabric API Builder Tools.
Give designers access to the Logic Fabric API Builder app.

Move APIs between environments as part of your Logic Fabric project with the Logic Fabric CLI: the project package carries its APIs and their versions. See also Installation for the platform as a whole.

The API host

The API host serves one API of one project from one Dataverse environment. Your hosting team builds it as an ASP.NET Core project (see Create the API host project), deploys it and configures it; as the API designer you provide the values below and agree how callers sign in.

Settings to agree with your hosting team

Setting	What it decides	What you provide
Dataverse environment	Where the host reads the API and the data.	The environment, and an application user with the privileges the API needs on the exposed tables and Dataverse actions.
Project and API	Which API the host serves.	The Logic Fabric project name and the API name, exactly as in Dataverse.
Version	Which version callers get.	One version per host: a specific published version, the latest published version, or (in development only) the draft. See Versions and updates. To serve several versions side by side, run one host per version at different addresses; callers choose the version by address.
Sign-in	How callers authenticate.	The identity provider your apps use (for example Microsoft Entra ID or your customer identity platform).
Roles and user properties	Which API roles and user property values each signed-in caller has.	Your role names and user properties from Context, and where each value comes from, for example a claim in the caller’s token, or a lookup in Dataverse. The host supplies them in its user resolver.
Address	The base address callers use.	The host name and any base path, for example `https://api.contoso.com/portal`.
API documentation	Whether the host publishes an OpenAPI page for developers.	Whether developers outside your team need it.

How it behaves

A version with errors isn’t served. If the version the host is asked to serve contains errors (for example an incomplete authorization policy), the host does not serve that version, and its log says why. Callers then can’t reach that version’s endpoints. Publish a fixed version.
New versions and the host. A host set to a specific version keeps serving that version until its setting changes. A host set to the latest version (or the draft) picks up a newly published version (or a saved draft) within a few minutes if its metadata watcher is on; see Versions and updates.
Data security. The host reads and writes Dataverse as its application user. Your authorization policies, preconditions and query conditions decide what each caller can do through the API; review them before you go live.

Before you go live

Every endpoint has an authorization policy, or is meant to be public.
The draft has no issues, and the version is published.
The hosting team has the project name, API name, version, role names and user properties.
A developer has generated the OpenAPI schema and tested the main calls.