Epicor Integration Guide: REST API, Service Connect & EDI
How REST APIs, Service Connect, EDI and iPaaS connectors link Epicor Kinetic to CRM, ecommerce and finance systems, and how to choose the right method for each.
A sales order keyed twice. A supplier invoice that never reaches the ledger. A price that differs between the webshop and the ERP. Epicor integration closes gaps like these by connecting Epicor Kinetic to the other systems a business runs on, so each record moves once, under clear rules, with a trail behind it.
The need is widespread. In MuleSoft's 2022 Connectivity Benchmark Report, produced with Deloitte Digital, organizations used 976 applications on average, yet only 28% were integrated.
This guide compares the main Epicor integration methods (REST APIs, Service Connect, EDI and integration platforms), explains the design decisions behind a reliable ERP integration layer, and shows where finance automation fits.
What Is Epicor Integration?
Epicor integration is the practice of connecting Epicor ERP, today mainly Epicor Kinetic, with other applications so that data and transactions move between them automatically under defined rules. An integration reads master data or transactions from Epicor, writes approved records into it, or both.
It works at two levels. Data integration moves records, such as a CRM customer appearing in Kinetic. Workflow integration coordinates a process, such as a web order becoming a sales order, shipment, invoice and tracking update.
Done poorly, integration just moves bad data faster. According to 2020 Gartner research, poor data quality costs organizations at least $12.9 million a year on average, and Gartner names inconsistency across siloed sources as the most challenging data quality problem. So every design must settle which system owns each record, who can write it, how often it syncs, and what happens when a message fails.
Common Epicor Integration Use Cases
Most Epicor integrations follow one of seven patterns.
Use case | Problem it solves | Typical data and direction | Watch for |
CRM | Sales and ERP disagree on customers, prices and order status | Accounts and orders into Epicor; order status and credit back to CRM | Agree which system owns customers and prices |
Ecommerce | Web orders re-keyed; online stock is stale | Orders in; inventory, prices and tracking out | Slow inventory sync causes overselling, a core risk in any ecommerce ERP setup |
EDI | Large customers and suppliers require standard documents | POs, ship notices, invoices and acknowledgments, both ways | Partner-specific maps and compliance deadlines |
Finance and accounting | Invoices keyed from PDFs; journals posted from spreadsheets | Suppliers, POs and receipts out; validated AP invoices and journals in | Epicor posting rules and periods apply across procure-to-pay and order-to-cash |
Banking and payments | Payment files and statements handled by hand | Payment runs out; statements and remittances in | File formats, segregation of duties, bank statement reconciliation |
Tax and procurement | Tax checked manually; requisitions approved by email | Tax codes, addresses, requisitions and POs, both ways | Epicor owns posted tax; sales tax verification catches mismatches |
Reporting and BI | Reports built from manual exports | GL, sales, inventory and production data out | Read-only access and incremental extracts protect production |
Coverage varies by Epicor release, so confirm which scenarios your version supports natively and which need a connector or partner work.
Epicor Integration Methods: REST API, Service Connect, EDI, and Connectors
Four methods cover almost every Epicor Kinetic integration. They are not interchangeable, and most companies use two or three.
Epicor REST API
Kinetic exposes its business objects (customers, sales orders, purchase orders, AP invoices and more) and saved queries called BAQs as REST services with OData query support. Writes call the same business object methods as Kinetic's screens, so Epicor's validations still run. The v2 API expects an API key on every request plus a user identity, and access scopes limit which services a key can reach.
Epicor API integration suits system-to-system transactions that need near real-time reads and controlled writes. The engineering is yours: idempotent writes, paging, retries with backoff, error handling, and regression tests after each Kinetic update.
Epicor Service Connect
Epicor describes Service Connect as a central platform for orchestrating workflows inside Epicor and with other applications, using XML, web services and visual designers for mapping, error handling and scheduling. It can exchange XML with EDI partners and add human steps such as email approvals.
Its lifecycle matters more than its features. An Epicor staff member wrote on the EpiUsers forum that Service Connect is off the price list, gets no new development, cannot run on an Epicor cloud instance, and is succeeded by Automation Studio. If you run Service Connect workflows today, keep them supported and plan to move their calls to REST.
EDI integration
EDI exchanges standardized documents, such as purchase orders, ship notices and invoices, with trading partners in formats like ANSI X12 or EDIFACT, over a VAN, AS2 or SFTP. Epicor sells its own Epicor EDI, which it says works with Kinetic, Prophet 21 and other ERPs, and third-party translators also connect to Kinetic. EDI is the contract with a retailer or OEM; APIs connect your own systems, so EDI integration with Epicor Kinetic rarely replaces API work.
Epicor integration method comparison
Integration method | Best-fit use cases | Key strengths | Limitations and considerations |
REST API | Real-time transactions; custom apps; finance automation that posts to Kinetic | Runs Epicor business logic; fine-grained; cloud and on-premises | Developer effort; you own retries, idempotency and monitoring; retest after updates |
Service Connect | Existing on-premises workflows and XML exchange | Visual designer; human workflow steps; logging | No new development per Epicor staff; not sold to new accounts; not on Epicor cloud |
EDI | Trading partner documents | Industry standards; often mandated; acknowledgments | Partner maps; translator and VAN costs; mostly batch |
Connectors and iPaaS | Common SaaS apps such as CRM and ecommerce | Faster build; templates; monitoring; Epicor-native options | Licensing; custom field gaps; vendor dependence; complex finance logic may need code |
No method wins outright. A common pattern is EDI for trading partners, iPaaS for standard SaaS apps, and REST for transactions that must post through Epicor's validations.
How Epicor Kinetic Integration Works
Whatever the tool, a reliable Epicor Kinetic integration settles eight design decisions. Picture an approved supplier invoice flowing from a capture system into Kinetic AP.
Source of truth. Epicor owns suppliers, GL accounts, POs, receipts and posted invoices; the capture system owns the invoice image and its processing state.
Mapping. Supplier IDs, units of measure, tax codes, GL segments, companies and user-defined fields need explicit rules. Tools that map custom fields and company-specific structures without code cut rework on customized Kinetic.
Timing. Use synchronous calls when a user waits and queues for bulk posting. Sync master data on a schedule and invoices or receipts in near real time.
Incremental reads. Read only what changed since the last run instead of reloading tables.
Idempotency. Key each message, for example supplier plus invoice number, so a retry updates rather than duplicates. Microsoft advises checking idempotency before retrying any operation.
Failure handling. Retry transient errors with backoff, route business errors such as a closed period to a person, and reconcile counts daily.
Security. A dedicated integration user, least-privilege scopes, vaulted keys and encrypted transport. On-premises Kinetic also needs a safe path for cloud apps, such as a gateway or outbound agent.
Lifecycle. Kinetic updates can change services, so keep a regression suite. Epicor's final on-premises Kinetic feature release, 2028.1, is tentatively set for January 2028, followed by Active and then Sustaining Support. Build for a cloud move: favor REST and avoid direct database writes.
This is a conceptual reference pattern: Kinetic supplies the services and security model, and the integration supplies keys, queues, retries and reconciliation.
How Hyperbots Integrates With Epicor Kinetic: Architecture and Persimmon Case Study
Hyperbots is an intelligence and automation layer for finance that works alongside Epicor Kinetic rather than replacing it. Kinetic remains the system of record for suppliers, POs, receipts and the ledger; Hyperbots HyperAGENTS do the document and decision work around those records, the pattern described in how AI complements ERP systems.
The architecture
Validated transactions flow into Epicor through its own services, while master data and posting status flow back. The Hyperbots Epicor connector reads and writes the following:
Data | Read from Epicor | Written to Epicor |
Suppliers, items, GL accounts, payment terms, companies | Yes | No |
Purchase orders, with per-line GL and invoiced quantities | Yes | Created from approved requisitions |
Receipts and receipt lines | Yes | No |
AP invoices | Status | Created, source PDF attached, posted |
Accrual journals | No | Booked and reversed |
How the connector writes to Kinetic
The connector drives Kinetic through its business objects, the same services Epicor's screens call, so nothing lands that Epicor would not accept from a person.
Native transport. A Kinetic token plus the tenant's API key; OData for reads and change tracking, business object methods for writes.
Invoices built Epicor's way. The Invoice Processing HyperAGENT creates an AP invoice group, header and lines, codes non-PO lines to GL, and matches PO lines to receipts through AI three-way matching.
No duplicates or half-built records. Group IDs derive from supplier and invoice number, so corrections replace rather than duplicate. If any step fails, the connector removes what it created.
Posted means posted. Posting runs Epicor's own pre-post checks and reports success only when Epicor confirms the invoice is posted.
Gentle sync. Reads track Epicor's row-revision number and fetch only changes, paged to protect production.
Actionable errors. Epicor's own error text appears in Hyperbots, failures alert in Slack or Teams, and field mappings are templates, so custom fields are configuration.
Epicor keeps posting rules, periods, security and reporting, with human-in-the-loop controls for anything outside tolerance. The documented Epicor scope is procure-to-pay and accruals; receivables write-back is confirmed during scoping.
Case study: Persimmon Technology
In Hyperbots' Epicor ERP integration case study, Dave Sackett, VP of Finance at Persimmon Technology, describes a deployment on on-premises Epicor:
Connectivity. A lightweight agent on the Epicor app server opens an outbound HTTPS tunnel, so no inbound firewall changes were needed. It calls Epicor REST v2, or Service Connect on older builds.
Cadence. Chart of accounts syncs weekly; suppliers, parts and GL codes daily; receipts and invoices hourly; writes in real time.
Controls. Every write is read back field by field; errors such as a closed period get three retries, then an exceptions queue and a Teams alert.
Results. About 80% of invoices flow straight from the AP mailbox to posted invoices in Epicor, and AP data entry fell 80%.
The rollout took 3 to 5 weeks with no custom code, faster than the 6 to 8 weeks Hyperbots typically needs for ERPs with an existing connector, including Epicor.
Common Epicor Integration Challenges and How to Address Them
Most failures trace back to data, ownership or visibility, not the connection itself.
Challenge | Why it happens | Mitigation |
Inconsistent master data | The same supplier or part is coded differently across systems | Name an owner per object; cleanse and cross-reference before go-live |
Incorrect field mappings | Units, tax codes, GL segments or UD fields misaligned | Map from a written spec; test with real historical transactions |
Duplicate transactions | Retries or resubmissions create a second record | Idempotency keys plus duplicate detection on supplier, amount, date and lines |
Partial or failed sync | One step of a multi-record write fails | Compensating rollback and daily reconciliation |
Authentication and permissions | Expired keys, missing scopes, shared logins | Dedicated integration user, least-privilege scopes, key rotation |
Changes after upgrades | Kinetic updates alter services or payloads | Regression tests before each update |
Latency and timing | Batch schedules miss receipts or stock changes | Match sync frequency to the decision the data drives |
Silent failures | Errors logged where nobody looks | Slack or Teams alerts and an owned exceptions queue |
Unclear ownership and weak audit trail | No owner for cross-system records | A named owner per integration; log each source document against its Epicor record ID |
How to Choose the Right Epicor ERP Integration Approach
Start from the use case, then let deployment, volume and team capacity narrow the method.
If your situation is | Lean toward |
A retailer or OEM mandates standard documents | EDI, via Epicor EDI or a third-party translator |
A common SaaS app with a maintained connector | Automation Studio, Integration Cloud or another iPaaS |
Finance transactions that must post through Epicor's validations | REST through business objects, in-house or via a specialist vendor |
High volume, near real-time needs | REST or queue-based iPaaS with incremental reads |
Existing Service Connect workflows | Keep them running; plan a move to REST or Automation Studio |
On-premises Kinetic connecting to cloud apps | An outbound agent or secure gateway, planned around 2028 |
A small IT team | A managed connector or vendor-run integration |
Strict audit requirements | Read-back verification, per-transaction logs and rollback |
Judge total effort, not build effort: mapping, monitoring and retesting after every Kinetic update continue for years. Vendors with maintained, plug-and-play ERP adapters carry part of that load, so ask who owns each task before you sign.
Building an Epicor Kinetic Integration Strategy That Lasts
Epicor Kinetic integration is a set of choices, not a single product. REST carries transactions that must pass Epicor's validations, EDI meets trading partner mandates, iPaaS connects standard apps quickly, and Service Connect keeps existing workflows running while you plan its successor.
The controls matter more than the method: a clear owner for every record, idempotent writes, verified posting, visible failures and a plan for the cloud. For finance workflows, a dedicated automation layer can supply those controls while Epicor stays the system of record.
See how Hyperbots HyperAGENTS work with Epicor Kinetic on your own invoices and POs. Request a demo.
Frequently Asked Questions About Epicor Integrations
Q1. Does Epicor Kinetic support REST APIs?
Yes. Kinetic exposes business objects and BAQs as REST services with OData support, and each instance publishes an interactive help page listing them. New integrations generally use the v2 API, which requires an API key on every request plus a user identity such as basic credentials or a token. Access scopes restrict each key to the services it needs.
Q2. What is Epicor Service Connect used for, and is it still supported?
Service Connect orchestrates workflows between Epicor and other applications using XML, web services and a visual designer, and many on-premises customers still run it. An Epicor staff member has said on the EpiUsers forum that it is no longer sold to new accounts or actively developed, with Automation Studio as its successor. Confirm your support status with Epicor before extending it.
Q3. What is the difference between Epicor API integration and EDI?
API integration connects applications to Kinetic directly, record by record, often in near real time. EDI exchanges standardized documents such as purchase orders and invoices with external trading partners, usually through a translator and a network. Most manufacturers and distributors need both: EDI where customers mandate it, APIs for internal systems.
Q4. Can Epicor Kinetic integrate with Salesforce or ecommerce platforms?
Yes, usually through an iPaaS connector or custom REST integration. Epicor's Automation Studio announcement uses a Salesforce opportunity creating an Epicor order as its example, and several platforms publish Shopify connectors. Decide early which system owns customers, prices and inventory, because that drives the sync direction for each object.
Q5. How do you monitor and troubleshoot Epicor integrations?
Log each request with its source document ID and the Epicor record ID it created. Alert on failures in a channel the team watches, keep an owned exceptions queue, and reconcile counts and totals daily. When a write fails, start with Epicor's returned error message, which usually names the field, period or rule that blocked it.
Q6. Will Epicor integrations still work after moving from on-premises to Kinetic cloud?
REST-based integrations generally carry over with new URLs, keys and network paths. Direct database writes and Service Connect running on the Epicor server will need rework, since Epicor community guidance says neither is available in its cloud. With the final on-premises feature release planned for January 2028, inventory your integrations now.
Q7. How long does an Epicor integration take?
It depends on the method, the number of objects and how customized Kinetic is. A connector for standard objects can go live in weeks; multi-system projects take longer. Hyperbots integrations on ERPs with an existing connector, including Epicor, typically take 6 to 8 weeks, and Persimmon Technology's on-premises rollout took 3 to 5.
