NetSuite, Epicor and SAP B1 integration: what a real build involves
Each ERP publishes its own way in. NetSuite through SuiteTalk and REST, Epicor Kinetic through a REST API, SAP Business One through its Service Layer. None of that tells you what your account actually exposes until someone checks.
Answered in short
5 things that decide this
- 01NetSuite integrates through SuiteTalk (SOAP and REST web services) plus SuiteApps reviewed on the SuiteApp Marketplace; Epicor Kinetic exposes a REST API for its ERP objects; SAP Business One offers the Service Layer, a REST-based OData interface, alongside the older DI API for desktop-style automation.
- 02Every one of these gates real integration behind account-specific setup: which modules a customer licenses, what roles and permissions their admin grants, and which endpoints their tenant actually turns on. We confirm exactly what an account exposes during the audit, before we scope a build against it.
- 03A real order-to-invoice build touches four points: order intake creates or updates the record, a traveler or work order writes progress back, job-cost data reads out for reporting, and a client or vendor portal reads a filtered slice of the same data.
- 04We have not shipped a NetSuite, Epicor or SAP B1 integration to date. What follows is the access model as each vendor documents it, and how we would approach a build against it once your account's specifics are confirmed.
- 05This page sets out the shape of the work, not a quote. Cost and scope come from the diagnostic, once we've seen what your instance actually exposes.
The API exists. Your account decides what it does
Search for any of these three ERPs and you'll find a documented API. That's true and also not the whole story. A published endpoint only means the vendor built it. Whether your specific tenant can call it depends on the modules you licensed, the roles your admin assigned, and whether your implementation partner turned that feature on in the first place.
NetSuite bundles SuiteTalk access into most editions, but the objects and fields you can reach still follow your role's permissions inside NetSuite itself. Epicor Kinetic's REST API sits behind the same licensing and configuration questions that govern any other module. SAP Business One's Service Layer needs the right database and company settings enabled before an external app can authenticate against it at all.
So the real starting question isn't "does this ERP have an API." It's "what does your account expose today, and who has to say yes before we can call it." That's what we confirm during the audit, against your own instance, not against the general docs.
Three different doors, three different keys
Here's what each vendor publishes about its own integration surface, and where the account-specific part begins.
- 01NetSuite: SuiteTalk web services (SOAP and REST) expose standard and custom records for reading and writing. SuiteApps, listed on the SuiteApp Marketplace, extend or integrate NetSuite for a specific customer or as a packaged product; a marketplace listing needs its own review process, separate from a private, single-tenant build.
- 02Epicor Kinetic: a REST API surfaces ERP objects such as orders, jobs and inventory. Which objects and fields your account can reach depends on the modules you've licensed and the security settings your Epicor admin configures.
- 03SAP Business One: the Service Layer is a REST-based OData interface for business objects, the modern route for most new integrations. The older DI API (Data Interface API) still exists for desktop-style automation on Windows. Which one fits depends on whether the integration runs as a service or alongside the client application.
- 04All three: authentication, available objects and write permissions are set per tenant, by that customer's own admin. There is no universal key that opens every account the same way.
- Confirm the modulesWhat's licensed and turned on in this account
- Confirm the rolesWho can grant API access, and what they can see
- Register or connectA SuiteApp, an Epicor API key, or a Service Layer session
- Scope the objectsOrders, jobs, inventory, whatever the build touches
- Build and testAgainst a sandbox or test company, before production
The API surface is public. The grant that makes it usable is not.
Four points, whichever ERP you run
Strip away the vendor-specific names, and most requests against these three ERPs land on the same four points. Each one has its own way of breaking, and none of them is harder than confirming access in the first place.
- 01Order intake: an email, PDF or EDI order becomes a sales order or work order in the ERP, with the right customer match, item codes and pricing carried across.
- 02Traveler or work order write-back: production progress, from the floor or a scanning step, updates the job or work order record so the ERP reflects what actually happened, not just what was planned.
- 03Job-cost reads: labor, materials and overhead pulled out on a schedule for dashboards the ERP's own reporting doesn't build, joined against payroll or shop-floor data outside the system.
- 04Client or vendor portals: a filtered view of orders, invoices or job status, built for people who should never see the full ERP screen.
The failure modes worth asking about
An ERP integration that works in a sandbox and breaks in production usually fails in one of these ways.
- 01Scope creep at the permission layer: the account grants read access to an object, not write, and a build that assumed both stalls mid-project.
- 02Custom fields nobody documented: manufacturers customize their ERP over years, and a build against generic API docs misses fields the account actually relies on.
- 03Sandbox and production drift: a test company doesn't mirror production configuration exactly, so an integration that passes testing meets a setting nobody replicated.
- 04Silent auth expiry: tokens and sessions expire on a schedule, and a build that doesn't handle renewal looks fine for weeks before it quietly stops writing anything.
Some of the systems we have shipped
Related questions
01Which of these three ERPs is easiest to integrate with?+
SAP Business One's Service Layer is a modern REST interface, which tends to be the most straightforward to build against once access is granted. NetSuite and Epicor are both well documented too. The harder part with all three is usually the account-specific grant, not the API's design.
02Can we get API access without our ERP vendor's consultant?+
Usually yes, if your own admin has the right role to grant it, but many manufacturers' ERP was implemented by a consultant who controls that configuration. Confirming who holds the keys is one of the first things we check during the audit.
03Do you need write access, or just read access?+
That splits by what you're building. A reporting dashboard often needs only read access, while order intake or traveler write-back needs write access to specific objects. Write access is the bigger ask of the account's permissions, and it usually needs sign-off from whoever owns the ERP.
04How long does an ERP integration project usually take?+
The timeline follows what your account exposes and how many objects the build touches, which is exactly why we don't quote a range before the diagnostic. A single write-back point is a different project from a full order-to-invoice pipeline.
05Has Hashlogics shipped a NetSuite, Epicor or SAP B1 integration before?+
Not yet. What's on this page is the access model as each vendor documents it, and the four-point pattern we'd build against any of them. We confirm your account's specifics during the audit before anything gets scoped or quoted.
Related
- AI, automation and custom software for manufacturers and logistics operators →The wider industrial work this page sits under.
- Custom software →Where integration and portal work like this lives.
- Manufacturing →The segment this integration question comes up most.
- Best MES software for small manufacturers →The shop-floor tools on the other end of an ERP write-back.
