REST, Service Connect, EDI and the D365 integration surface

How Epicor Kinetic's REST API v2 / OData v4, Service Connect and Integration Cloud, EDI via third parties, published web services, direct database extracts and Task Agent scheduled jobs translate into D365 data entities, OData, custom services, business events, dual-write, virtual entities, Azure integration services and the Fabric analytics link.

What you will be able to do

• Inventory every Epicor integration surface and classify it by direction, volume, latency and error-handling behaviour
• Map each Epicor integration pattern to the correct D365 mechanism
• Explain why direct database reads have no D365 equivalent and what replaces them
• Choose between DMF, OData, custom services, business events and dual-write for a given workload
• Design the integration inventory as a first-class discovery artefact with a named owner per interface
• Plan the EDI trading-partner re-onboarding as a parallel workstream

Introduction

Epicor Kinetic's integration surface is shaped by the ICE framework's service-oriented architecture: business objects exposed over REST and OData, a proprietary orchestration engine (Service Connect), hosted connectors (Integration Cloud), and a scheduling agent (Task Agent).

The integration inventory as a discovery artefact

Before any design work begins, the programme must produce a complete integration inventory — every interface that crosses the Epicor boundary, documented with enough detail to make a platform decision. This is not optional and it is not a spreadsheet someone fills in later.

Epicor's integration surface — what you are leaving behind

Epicor's REST API v2 exposes business objects, BAQ results, server-side processes and Epicor Functions over OData v4 with full CRUD capability. Authentication is API-key plus Basic or OAuth. This is the strategic modern integration API and, for cloud-hosted Epicor instances, often the only programmatic extraction channel available.

The D365 integration estate — what you are moving to

Data entities are shaped, validated views over D365 tables, designed for integration and data movement. They enforce business rules on write, support set-based operations, and are the backbone of DMF import and export projects. The Data management framework orchestrates entity-based imports, exports, recurring jobs and data packages.

Mapping Epicor patterns to D365 — the decision table

Re-authentication and the security model shift

Every Epicor integration authenticates via API key plus Basic authentication or OAuth against the Epicor server. D365 integrations authenticate via Azure AD — service principals, client credentials, or managed identities. The shift is fundamental:

The Epicor-specific traps

Epicor estates running on-premises often have 20–50 integrations that read the database directly — warehouse systems pulling pick lists, BI tools running nightly extracts, shop-floor systems polling job status. None of these integrations were formally designed against the business-object layer because they did not need to be.

Knowledge check

Summary

The Epicor-to-D365 integration workstream is defined by one structural fact: direct database access disappears, and everything that relied on it must be re-routed through a governed integration layer.