Every Epicor Kinetic installation I've worked on has at least one integration that someone built years ago and nobody fully understands anymore. Sometimes it's a CSV file that gets dropped into a folder at 2 AM. Sometimes it's a web service that somebody's predecessor wrote in VB.NET. Sometimes it's a person named Steve who manually copies data from a spreadsheet into Epicor every morning before the planning meeting.
All of these are "integrations." Some work fine. Most are fragile. And nearly all of them become a problem when the company upgrades to Kinetic or moves to Epicor Cloud, because the old approach either stops working entirely or becomes unsupportable.
I spend a lot of my time on Epicor integration consulting — connecting Kinetic to WMS systems, e-commerce platforms, EDI providers, shipping APIs, and various custom applications that manufacturers have built internally. This article is what I wish someone had given me when I started doing this work: an honest breakdown of what each integration approach actually looks like, what it costs, and where things go wrong.
The Epicor REST API — Where Most Integrations Start
Since Epicor Kinetic 2021.1, the REST API has been the primary way to connect external systems to Epicor. It's an OData v4-based API that exposes almost every business object in the system — Sales Orders, Purchase Orders, Parts, Customers, Inventory, Jobs, you name it.
When someone says they need "Epicor integration consulting," they usually mean they need someone who can build and maintain REST API connections between Epicor and one or more other systems. And honestly, the API itself isn't that hard. What's hard is everything around it.
What makes Epicor REST integrations tricky
- 🔑 Dual authentication — you need both an API Key and Basic Auth on every request. Miss one, you get a 401 that tells you nothing useful.
- 🏭 Company context — every API call runs in the context of a company and plant. Get the wrong company header and you're writing data to the wrong entity.
- 📦 Business Object methods matter — you can't just POST a JSON blob. You need to call GetNew, set fields, then call Update in sequence. The API mirrors the UI's business logic, which means you inherit its quirks too. I cover this pattern in detail in my REST API Integration Tutorial.
- ⏱ Performance under load — calling the API 500 times per minute to create sales order lines is very different from calling it 5 times. Batch operations, connection pooling, and rate limiting all come into play.
- 🔄 Error handling is on you — the API returns 500 errors with BPM exception messages buried in the response body. If you don't parse and log these, you'll have silent failures that nobody notices until month-end close.
I've written more about the authentication side of this in my REST API Authentication Troubleshooting article, so I won't repeat that here. The point is: the REST API is powerful and well-designed, but it has a learning curve that catches people who are used to simpler REST services.
The 5 Integrations I Build Most Often
Every manufacturer's needs are slightly different, but these five come up on almost every engagement:
📦 1. WMS (Warehouse Management System)
What connects: Inventory receipts, picks, shipments, transfers, cycle counts, bin movements.
How it usually works: The WMS sends completed transactions to Epicor via REST API calls — confirming receipts, recording picks against pack slips, and updating inventory quantities. Epicor sends work orders and expected receipts to the WMS.
Where it breaks: Timing. If the WMS confirms a shipment before Epicor has created the pack slip, the API call fails. I've also seen quantity mismatches when partial picks aren't handled correctly — the WMS says "picked 47 of 50" and the integration tries to ship 50. You need robust partial-quantity logic and a retry queue for out-of-sequence transactions.
🛒 2. E-Commerce (Shopify, WooCommerce, Magento, BigCommerce)
What connects: Customer creation, sales order entry, inventory availability, pricing, order status/tracking.
How it usually works: Orders placed on the web store automatically create Sales Orders in Epicor via REST API. Inventory levels sync back to the store periodically (every 5–15 minutes) so customers see accurate stock counts. Tracking numbers push back after shipment confirmation.
Where it breaks: Customer matching. The web store creates a new customer record every time, but Epicor needs a proper CustID. You need deduplication logic — match on email, company name, or tax ID before creating a new customer. I've cleaned up databases where the same customer had 15 different CustIDs because nobody built matching logic. Also: pricing discrepancies. If the web store has a discount that doesn't exist in Epicor's price list, the order total won't match and Finance will call you.
📄 3. EDI (Electronic Data Interchange)
What connects: Purchase orders (850), invoices (810), advance ship notices (856), functional acknowledgments (997).
How it usually works: An EDI translator (SPS Commerce, TrueCommerce, or similar) converts X12/EDIFACT documents into structured data. That data feeds into Epicor via REST API or DMT to create/update sales orders, generate invoices, and send ship confirmations. Most EDI providers offer Epicor-specific connectors that handle the mapping.
Where it breaks: Trading partner requirements. Every major retailer (Walmart, Amazon, Home Depot) has slightly different EDI requirements — specific field mappings, mandatory segments, timing windows for ASN submission. Miss a required field and your shipment gets charged back. This isn't an Epicor problem specifically, but the person building the integration needs to understand both the EDI spec and Epicor's data model well enough to map between them accurately.
🚚 4. Shipping Carriers (UPS, FedEx, USPS, LTL)
What connects: Rate shopping, label generation, tracking number capture, freight cost recording.
How it usually works: When a pack slip is ready to ship, the integration calls the carrier's API to generate a label, pulls back the tracking number and freight cost, and writes those to the Epicor ShipHead/ShipDtl records. Some companies use ShipStation or ShipWorks as a middle layer.
Where it breaks: Weight and dimension data. If your parts don't have accurate weight fields in Epicor, the rate request returns wrong pricing. I always tell clients: get your Part Master weight data right before we start the shipping integration, not after. It saves weeks of back-and-forth with incorrect freight charges.
📊 5. BI / Reporting (Power BI, Tableau, Custom Dashboards)
What connects: Sales data, production metrics, inventory levels, financial KPIs, customer analytics.
How it usually works: Either direct SQL Server connection to the Epicor database (read-only replica recommended) or BAQ-based data exports via REST API. Power BI can connect to Epicor BAQs directly using the OData endpoint, which is actually one of the cleaner integration patterns available.
Where it breaks: Performance. If your Power BI dashboard runs a complex BAQ across 2 million PartTran records every time someone opens it, your Epicor server will feel it. Use incremental refresh, limit date ranges, and consider a data warehouse (even a simple SQL staging database) for heavy reporting workloads. Don't hit the live transactional database with analytical queries during business hours.
Middleware vs. Direct API: When Each Makes Sense
This question comes up on literally every integration project. Should we use middleware (Boomi, MuleSoft, Celigo, Workato) or just write direct REST API calls?
My honest answer: it depends on how many systems you're connecting and how much you want to manage yourself.
| Scenario | My Recommendation | Why |
|---|---|---|
| 1 system, simple sync | Direct REST API | Middleware licensing costs don't justify a single connection. A Node.js or C# service handles it fine. |
| 2–3 systems, moderate volume | Either works | Depends on internal IT capability. If you have a developer who can maintain custom code, direct is cheaper. If not, middleware gives you a visual interface. |
| 4+ systems, high volume | Middleware (Boomi, Celigo) | Centralized logging, retry queues, transformation maps, and monitoring become essential. Managing 4+ custom integrations without middleware is a maintenance nightmare. |
| EDI with 10+ trading partners | EDI provider + middleware | SPS Commerce or TrueCommerce handles the trading partner maps. Middleware handles the Epicor side. Don't build EDI translation yourself. |
One thing I'll add: I've seen companies buy Boomi licenses for $25k/year to handle one Shopify integration. That's overkill. On the other hand, I've seen companies try to maintain five custom Python scripts connecting Epicor to their WMS, EDI, e-commerce, shipping, and BI platform — and the developer who wrote them left two years ago. Nobody can debug the scripts, nobody knows where they're hosted, and there's no error alerting. That's worse.
Match the tool to the complexity. Don't underbuild, but don't overbuy either.
What Epicor Integration Projects Actually Cost
I get asked about pricing on every discovery call, so I'll be direct. These are the ranges I see across my projects and the broader Epicor consulting market:
| Integration Type | Cost Range | Timeline |
|---|---|---|
| Simple one-way data push (e.g., orders from Shopify) | $5,000–$15,000 | 2–4 weeks |
| Bi-directional real-time (e.g., WMS ↔ Epicor) | $15,000–$50,000 | 4–10 weeks |
| Full EDI setup (5–10 trading partners) | $20,000–$60,000 | 6–12 weeks |
| Multi-system integration hub (WMS + EDI + e-commerce) | $60,000–$150,000+ | 3–6 months |
These numbers assume an independent consultant rate. If you're going through a large consulting firm, multiply by 1.5–2x for the same deliverable. I talked about why in my Independent Consultant vs Firm comparison.
"We were quoted $85,000 for a WMS integration by a firm. An independent consultant did it for $28,000 and it actually works better because the same person who designed it built it and debugged it."
— Thread on epiusers.help, Epicor WMS Integration Recommendations
How to Scope an Integration Project Without Getting Burned
Most integration projects that go over budget do so because nobody asked the right questions upfront. Here's the scoping checklist I use on every engagement:
- What's the data direction? One-way push, one-way pull, or bi-directional? Bi-directional doubles the complexity and more than doubles the testing.
- What's the transaction volume? 50 orders per day is a completely different architecture than 5,000 per day. High-volume integrations need queue-based processing, batch operations, and monitoring that low-volume ones don't.
- What happens when it fails? This is the question nobody wants to answer during scoping but determines 40% of the development effort. Retry logic, dead-letter queues, alerting, manual override procedures — all of this needs to be defined before development starts.
- Who owns the other system's API? If you're integrating with a vendor-hosted WMS, can you actually get API documentation? Do they have a sandbox environment? Will their team be available for joint testing? I've had projects stall for weeks because the WMS vendor was unresponsive during the integration phase.
- What custom fields are involved? If you're passing data into UD fields on Sales Orders or Parts, those fields need to exist and be correctly typed before development starts. Sounds obvious, but I've shown up to kick off an integration and discovered the UD fields hadn't been created yet.
- What BPMs fire on the affected Business Objects? If you're creating Sales Orders via API and there's a Data Directive on OrderHed that sends an email notification on every new order, your integration will send 500 emails on the first sync. Map existing BPMs before you start writing API calls.
- What's the go-live cutover plan? Will you run both the old and new integration in parallel? How long? What's the rollback procedure? Don't go live on a Friday.
Mistakes I've Seen (and Made) on Integration Projects
I'm including my own errors here because I think it's more useful than pretending integration work goes smoothly every time:
- ⚠Not testing with production-volume data. An integration that works with 10 test orders will choke on 500 real ones if you haven't load tested. I learned this the hard way on a Shopify integration where Black Friday traffic was 20x normal. The API calls queued up and the whole thing fell over.
- ⚠Ignoring timezone differences. The WMS records timestamps in UTC. Epicor uses the server's local time. Your e-commerce platform uses the customer's timezone. If you're comparing timestamps across systems without normalizing to UTC, you'll get phantom duplicate records or missed transactions.
- ⚠No idempotency. If the same order gets sent twice (because of a network timeout and retry), does the integration create a duplicate Sales Order? It shouldn't. Every integration needs a way to detect and skip duplicates — usually by checking for an existing order with the same external reference ID before creating a new one.
- ⚠Building the integration before fixing the master data. Your Part Master has 200 parts with no UOM, your Customer Master has duplicates, and your price lists haven't been maintained since 2021. If you build the integration on top of bad master data, the integration will faithfully reproduce every data quality problem at machine speed. Clean the data first.
- ⚠No monitoring after go-live. The integration worked perfectly for 3 weeks. Then a WMS update changed a field name in their API response. The integration started silently failing. Nobody noticed for 4 days until the warehouse manager asked why no new pick lists were coming through. Always build alerting: if the integration hasn't processed a transaction in X minutes during business hours, send a notification.
Frequently Asked Questions
Can Epicor Kinetic integrate with third-party systems?
Yes. Epicor Kinetic has a full REST API (OData v4) that lets you connect to virtually any external system — WMS, e-commerce, EDI, shipping, CRM, BI tools, custom apps. Both real-time and batch integration patterns are supported.
What's the best way to integrate Epicor with a WMS?
REST API calls between the WMS and Epicor Kinetic, handling receipts, picks, shipments, and transfers in near real-time. For high-volume warehouses, add a middleware layer for queuing and retry logic. DMT batch imports work for simpler, lower-volume setups.
How much does an Epicor integration project cost?
Simple one-way integrations run $5,000–$15,000. Bi-directional real-time integrations are $15,000–$50,000. Complex multi-system hubs (WMS + EDI + e-commerce) can exceed $100,000 depending on volume and business logic.
Should I use middleware or direct API calls?
For a single integration, direct REST API calls are simpler and cheaper. For 3+ systems or high transaction volumes, middleware (Boomi, Celigo, MuleSoft) provides centralized logging, retry logic, and monitoring that custom code can't easily match.
Related Articles & Services
- Epicor REST API Authentication Troubleshooting — Fix 401 and 403 errors on your integration calls.
- Epicor Integration Middleware Comparison — Boomi vs. MuleSoft vs. Celigo vs. custom code.
- Independent Consultant vs Firm — Why integration projects cost 40–60% less with an independent.
- Epicor REST API Integration Services — Direct, hands-on integration development and support.
Need Help Connecting Epicor to Your Other Systems?
I'm Amit Nale — I've built Epicor integrations with WMS platforms, Shopify, EDI providers, shipping carriers, and Power BI. No middleware markup, no account managers. Just the person who designs the integration, builds it, tests it, and supports it after go-live.
Book a Free Integration Discovery Call