EasyPick Integrations
Inyxa EasyPick seamlessly connects with your existing ERP systems, devices, printers, and automation equipment to create a unified warehouse and manufacturing ecosystem. By integrating with the tools you already use, EasyPick ensures real-time data flow, accurate task execution, and enhanced operational efficiency across your operations.
How EasyPick integrates, on every platform.
One inventory record, not two.
EasyPick is a warehouse execution layer and holds no stock ledger of its own, so there is nothing to reconcile between two systems. Every movement posts to your ERP synchronously at the point of scan and the operator’s screen does not advance until the ERP confirms. If the ERP is unreachable, stock-affecting work stops rather than queuing against a stock position nobody validated. Push notification is used where the platform supports it, with a scheduled poll underneath it in every case. And no middleware: EasyPick consumes each platform’s own published API surface, so there is nothing between your ERP and your warehouse that has to be re-tested at every upgrade
Oracle E-Business Suite
Supported: Oracle E-Business Suite 12.1 and 12.2, on premises or on Oracle Cloud Infrastructure.
EasyPick does not connect to EBS across a network. It installs as a package into its own schema on the same Oracle database as EBS, and the scanner application is a front end to it. The EasyPick service is co-located with your EBS installation, inside your own network. There is no integration layer, because there is nothing to integrate across, and EasyPick stores no customer data of its own.
1. Authentication and Security
Authorization is governed by E-Business Suite itself. EasyPick is delivered with responsibilities and menus, so who may perform which transaction, in which organization, is controlled by EBS function security rather than by a separate permission model you have to maintain in parallel. The schema runs under a dedicated database account with grants limited to the public APIs and interface objects the package uses. Nothing is exposed to the internet, and there is no external service in the path of a scan.
2. Master Data Synchronization
There is none, and that is the point. Items, units of measure, cross references and barcodes, subinventories and locators, lot and serial attributes including expiry, and customer and supplier detail are all read from the EBS tables where they already live, at the moment the operator scans. Nothing is copied into EasyPick, cached in a cloud, replicated or reconciled. The only data held in the EasyPick schema is task state, scan history and configuration, and it sits in the same database under the same backup, the same DBA and the same audit.
3. Transactional Data Synchronization
There is no synchronization to perform. Every warehouse movement — receipt, inspection and disposition, putaway, subinventory and locator transfer, move order confirmation, material status change, pick, pack, ship confirm, cycle count, physical count, component issue and job completion — is created by a PL/SQL call in the same session and committed in the same transaction as the EBS record. Real time is not a design goal here; it is a property of running in the same database. If the posting fails, the scan fails, and the operator is told why while the material is still in front of them.
4. API Endpoints and Data Mapping
The package calls Oracle’s own public APIs and open interfaces throughout — receiving, inventory transactions, move orders, shipping, counting and WIP — and never writes to base tables. Every movement EasyPick creates is an ordinary EBS transaction with ordinary accounting, ordinary audit and ordinary Oracle support. There is no mapping layer, because there is no format conversion between two systems. Which API serves a given transaction depends on your release and on whether Oracle WMS or Mobile Supply Chain Applications is licensed, and that is confirmed against your instance during setup.
5. Middleware or Integration Platform
Not required, and neither is an integration. No ESB, no iPaaS, no Oracle Integration Cloud, no message broker and no cloud tenant. There is nothing between EasyPick and E-Business Suite to license, monitor, secure or re-test at every patch.
6. Error Handling and Monitoring
Oracle’s own error text is surfaced directly to the operator on the device, so a closed period, a failed lot validation or an unavailable locator is corrected on the spot rather than becoming a support ticket. Because the work commits with the EBS transaction, there is no partial state to clean up and no queue to replay. Concurrent programs handle reconciliation, purge and housekeeping on your existing scheduler, and monitoring uses the EBS tools your DBA already runs
7. Testing and Validation
The transactions are pre-built and pre-validated rather than developed per customer, so testing is verification of configuration rather than of new code. Validation is performed against a clone of your own instance, covering the organizations, sub inventories and transactions you have switched on, before anything is enabled in production.
Oracle Cloud ERP
Supported: Oracle Fusion Cloud Inventory Management, REST API 11.13.18.05 and later.
EasyPick connects directly to Fusion with no middleware. Oracle’s own 3PL and warehouse reference architecture normally assumes Oracle Integration Cloud sits in the path; EasyPick does not need it. Fusion stays the inventory record, and EasyPick uses the inbound REST resources that Oracle publishes specifically for warehouse integration. Typical Fusion connection time is four to six weeks.
1. Authentication and Security
OAuth 2.0 over HTTPS against a dedicated integration user, scoped by role to the inventory organizations EasyPick operates. Warehouse operators never authenticate to Fusion and consume no Fusion licences.
2. Master Data Synchronization
Items and cross references, inventory organizations, subinventories and locators, and lot and serial attributes including expiry are read from the Fusion REST catalogue and cached in EasyPick for instant scanner validation. Refreshed on change, with full nightly reconciliation. EasyPick never creates or amends Fusion master data, and does not synchronise supplier or customer master data; party detail arrives embedded on the orders EasyPick fetches.
3. Transactional Data Synchronization
Real time in both directions. Fusion raises inventory business events built specifically for 3PL and warehouse integration — Outbound Receipt Advice, Create Inbound ASN, Outbound Shipment Request and Create Movement Request — and these are configured under Manage Inventory Business Event Configurations with REST nominated as the transport, so Fusion calls EasyPick directly. EasyPick treats each event as a notification and reads the current document from Fusion. Every warehouse movement posts back synchronously at the point of scan. The operator’s screen does not advance until Fusion confirms.
4. API Endpoints and Data Mapping
Oracle’s published inbound resources are used throughout, including receivingReceiptRequests, receivingReceiptTransactionRequests, inventoryStagedTransactions, interfacedPickTransactions, shipmentTransactionRequests, shipmentLineChangeRequests, inventoryBalanceTransactions and inventoryOnhandBalances. Several of these stage to interface tables; EasyPick drives the processing step in the same call rather than leaving work on a scheduled sweep, which is what makes the posting synchronous.
5. Middleware or Integration Platform
Not required. No Oracle Integration Cloud, no ESB, no iPaaS, and no customisation to Fusion. Fusion-side setup is user and role creation plus enabling the inventory business events for the organizations in scope.
6. Error Handling and Monitoring
Fusion’s own error text is surfaced directly to the operator on the device. Every posting carries a unique EasyPick transaction reference, preventing duplicates and giving each movement a two-way trace. On a timeout EasyPick verifies before it retries. A daily reconciliation compares EasyPick’s transaction log against Fusion to a zero-discrepancy target.
7. Testing and Validation
Every resource is verified against your own pod before build. Full end-to-end validation is completed in your test pod before go-live, with a documented test
script covering both inbound notification and outbound posting
SAP
Supported: SAP S/4HANA (on premise, private and public cloud) and SAP ECC 6.0 EHP6–EHP8.
EasyPick connects directly to SAP with no middleware. It consumes SAP’s own released OData APIs and business events, which is SAP’s supported integration surface, so there is no integration platform to license, no custom interface layer to build, and nothing between your ERP and your warehouse that has to be re-tested at every upgrade. Typical SAP connection time is two to four weeks.
1. Authentication and Security
OAuth 2.0 against the SAP Gateway, with X.509 client certificates supported as an alternative. Dedicated technical users are scoped to only the plants, storage locations, movement types and shipping points EasyPick needs, so access is provably limited and read activity is separated from posting activity.
2. Master Data Synchronization
Materials, units of measure, barcodes, batches with expiry and status, plants and storage locations are read from SAP’s released OData services and cached in EasyPick for instant scanner validation. Refreshed on change through SAP business events, with full nightly reconciliation. EasyPick never creates or amends SAP master data.
3. Transactional Data Synchronization
Real time in both directions. SAP business events notify EasyPick the moment a purchase order, delivery or production order changes, and EasyPick reads the current document straight from SAP. Every warehouse movement — goods receipt, putaway, quality hold and release, transfer, pick, pack, goods issue, cycle count and production confirmation — posts back to SAP synchronously at the point of scan, creating standard SAP documents. The operator’s screen does not advance until SAP confirms the posting.
4. API Endpoints and Data Mapping
Standard released SAP APIs are used throughout, including Material Document, Inbound and Outbound Delivery, Purchase Order, Sales Order, Product, Batch, Physical Inventory, Production Order and Inspection Lot. Because these carry SAP stability contracts, the integration survives Feature Pack Stack upgrades without rework.
5. Middleware or Integration Platform
Not required. No SAP PI/PO, no SAP Integration Suite, no third-party ESB, and no ABAP development. SAP-side setup is a defined list of standard service activations and authorisation roles, typically a few days of work for one SAP administrator.
6. Error Handling and Monitoring
SAP’s own message text is surfaced directly to the operator on the device, so a blocked batch or an expired lot is corrected while the material is still in front of them. Every posting carries a unique transaction reference written into the SAP document, preventing duplicate postings, and a daily reconciliation report compares EasyPick’s transaction log against SAP document data to a zero-discrepancy target.
7. Testing and Validation
Every service is verified against the customer’s own system metadata before build, so the integration is developed against what that system actually exposes rather than a generic specification. Full end-to-end validation is completed in the SAP test environment before go-live, with a documented test script covering both inbound notification and outbound posting.
Oracle NetSuite
Supported: Oracle NetSuite with SuiteTalk REST web services, and bin or lot tracking enabled.
EasyPick connects directly to NetSuite with no middleware, using standard records only. NetSuite stays the inventory record. Typical NetSuite connection time is three to five weeks.
1. Authentication and Security
OAuth 2.0 over HTTPS against a purpose-built integration role carrying only the record permissions EasyPick needs, never Administrator. Warehouse operators authenticate to EasyPick and never sign in to NetSuite, so they consume no NetSuite licenses.
2. Master Data Synchronization
Inventory items and units of measure, barcodes, locations, bins, and lot and serial numbers including expiry are read through SuiteTalk REST and cached for instant scanner validation. Refreshed on change, with full nightly reconciliation. EasyPick never creates or amends NetSuite master data, and does not synchronise customer or vendor master data; party detail arrives embedded on the orders EasyPick fetches, so we only hold data for orders you are actually fulfilling.
3. Transactional Data Synchronization
Real time in both directions. NetSuite has no native webhook bus, so EasyPick ships a small SuiteApp of user event scripts that post the record type and internal ID the moment a record is committed. Nothing is transformed, and no business logic sits in the script, which keeps it inside NetSuite’s governance limits and trivial for your administrator to review. EasyPick then reads the current record. Every warehouse movement — receipt, bin putaway and transfer, location transfer, inventory status change, pick and fulfilment, pack and ship confirm, work order issue and completion, count and adjustment — posts back synchronously at the point of scan. The operator’s screen does not advance until NetSuite confirms.
4. API Endpoints and Data Mapping
Standard SuiteTalk REST record endpoints are used throughout, with NetSuite’s own record transforms for the posting path so a receipt or fulfilment is created exactly as it would be in the user interface. SuiteQL covers live on hand by bin and lot, and the delta sweep. REST enforces NetSuite’s business rules, permissions and scripts, so a posting made by EasyPick behaves the same as one made by a user.
5. Middleware or Integration Platform
Not required. No ESB, no iPaaS, no RESTlets and no SuiteScript business logic; the only script we ship is a notification stub, and EasyPick runs on the SuiteQL delta sweep alone if you would rather not install it.
6. Error Handling and Monitoring
NetSuite’s own error text is surfaced directly to the operator on the device. Every posting carries a unique EasyPick external ID on the NetSuite record, preventing duplicates and giving each movement a two-way trace. On a timeout EasyPick verifies by external ID before it retries. A daily reconciliation compares EasyPick’s transaction log against NetSuite to a zero-discrepancy target.
7. Testing and Validation
Every record type and field is verified against your own account before build. Full end-to-end validation is completed in a sandbox account before go-live, with a documented test script covering both inbound notification and outbound posting.
Infor M3
Supported: Infor M3 CloudSuite (multi-tenant) and Infor M3 13.4 on premises.
EasyPick connects directly to M3 through Infor's own ION API Gateway with no middleware.
M3 stays the inventory record. M3 also ships a Warehouse Management Interface for warehouses handed over to an external system, and EasyPick deliberately does not use it, because that model requires a second stock position and a documented manual reconciliation. Typical M3 connection time is four to six weeks.
1. Authentication and Security
OAuth 2.0 through the ION API Gateway using a Backend Service authorized app and its .ionapi credential. The service account is registered as an M3 user and restricted by API transaction and by role to only the warehouses and transactions EasyPick needs. Operators authenticate to EasyPick and never to M3, so they consume no M3 licences.
2. Master Data Synchronization
OAuth 2.0 through the ION API Gateway using a Backend Service authorized app and its .ionapi credential. The service account is registered as an M3 user and restricted by API transaction and by role to only the warehouses and transactions EasyPick needs. Operators authenticate to EasyPick and never to M3, so they consume no M3 licences.
3. Transactional Data Synchronization
Real time in both directions. M3 Event Hub, Event Analytics and the BOD Processor publish Business Object Documents the moment a purchase order, sales order, delivery, count, hold or production order changes, and an ION document flow delivers that notification to EasyPick through an ION API connection point. EasyPick then reads the current document from M3. Every warehouse movement posts back to M3 synchronously at the point of scan, executing inline rather than queuing as a batch message. The operator’s screen does not advance until M3 confirms.
4. API Endpoints and Data Mapping
Standard M3 API programs are used throughout, including MMS200MI, MMS025MI, MMS010MI, MMS060MI, MMS300MI and MMS301MI for reads, and MHS850MI, MMS850MI and MWS420MI for postings. M3 exposes more than 6,000 API transactions and publishes its own metadata through MRS001MI, so every transaction and field is confirmed against your tenant before build.
5. Middleware or Integration Platform
Not required. The ION API Gateway and ION Connect are components of Infor OS that you already own and administer. No ESB, no iPaaS, no Infor Enterprise Collaborator development, and no modification to M3.
6. Error Handling and Monitoring
M3’s own message text is surfaced directly to the operator on the device. Every posting carries a unique EasyPick message number written into the M3 record, preventing duplicates and giving each movement a two-way trace. On a timeout EasyPick verifies before it retries. A daily reconciliation compares EasyPick’s transaction log against M3 to a zero-discrepancy target.
7. Testing and Validation
Every API transaction and field is verified against your own tenant before build. Full end-to-end validation is completed in your test tenant before go-live, with a documented test script covering both inbound notification and outbound posting.
Infor LN
Supported: Infor LN 10.7, 10.8 and LN Cloud, through the ION API Gateway.
EasyPick connects directly to LN with no middleware. LN stays the inventory record. LN ships a WMS Interface for warehouses handed over to an external system, and EasyPick deliberately does not use it: in a WMS-controlled warehouse, adjustment orders, back flushing, blockings, package definitions and warehouse inspections must all be initiated in the external system, and a periodic reconciliation between the two systems is required. Typical LN connection time is five to seven weeks.
1. Authentication and Security
OAuth 2.0 through the ION API Gateway using a Backend Service authorized app. LN’s business interfaces are reached through the Connector for Web Services and registered as an LN API suite. For on-premises LN the ION Enterprise Connector provides the secure path without opening your network. Operators never authenticate to LN.
2. Master Data Synchronization
Items and units, warehouses and warehouse-item data, locations and storage zones, and lots and serials with expiry are read from LN’s business interfaces and cached for instant scanner validation. Refreshed on change, with full nightly reconciliation. EasyPick never creates or amends LN master data, and does not synchronise customer or supplier master data.
3. Transactional Data Synchronization
Real time in both directions. LN publishes Business Object Documents to ION through the Infor ERPLN connection point, covering item master, purchase and sales orders, receipts, shipments, inventory counts and adjustments. An ION document flow delivers the notification to EasyPick, which then reads the current document from LN. Every warehouse movement — receipt, inspection, putaway, transfer, block and release, pick, pack, ship confirm, cycle count, material issue and production receipt — posts back to LN synchronously at the point of scan. The operator’s screen does not advance until LN confirms.
4. API Endpoints and Data Mapping
LN’s business interfaces are consumed through the Connector for Web Services. LN’s interfaces are SOAP rather than REST, which is a difference in wiring rather than capability; the ION API Gateway fronts them with the same OAuth security as any other Infor suite. Interface names are confirmed against your own release before build, because the set varies between LN versions.
5. Middleware or Integration Platform
Not required. ION is a component of Infor OS that you already own. No ESB, no iPaaS, no LN customisation and no direct database access.
6. Error Handling and Monitoring
LN’s own message text is surfaced directly to the operator on the device. Every posting carries a unique EasyPick transaction reference written into the LN record, preventing duplicates and giving each movement a two-way trace. On a timeout EasyPick verifies before it retries. A daily reconciliation compares EasyPick’s transaction log against LN to a zero-discrepancy target.
7. Testing and Validation
Every interface and field is verified against your own environment before build. Full end-to-end validation is completed in your test environment before go live, with a documented test script covering both inbound notification and outbound posting.
Microsoft Dynamics 365 Business Central
Supported: Dynamics 365 Business Central online and on premises, API v2.0.
EasyPick connects directly to Business Central with no middleware and no Power Platform component in the posting path. Business Central stays the inventory record. Typical Business Central connection time is three to five weeks.
1. Authentication and Security
Microsoft Entra ID OAuth 2.0 service-to-service client credentials against an application user scoped by permission set to the locations EasyPick operates. Warehouse operators authenticate to EasyPick and never sign in to Business Central, so they consume no Business Central licenses.
2. Master Data Synchronization
Items and variants, units of measure, item references and barcodes, locations, bins and bin contents, and lot and serial information including expiry are read and cached for instant scanner validation. Refreshed on change, with full nightly reconciliation. EasyPick never creates or amends Business Central master data, and does not synchronise customer or vendor master data; party detail arrives embedded on the orders EasyPick fetches.
3. Transactional Data Synchronization
Real time in both directions. Business Central has a native webhook subscription API; EasyPick registers subscriptions against the resources it needs, completes the validation handshake and renews them automatically before the three-day expiry. Notifications carry the resource URL and change type only, so EasyPick re-reads current state rather than trusting a payload. Every warehouse movement — warehouse receipt, put-away registration, bin transfer, reclassification, quality hold via lot status, pick registration, shipment posting, adjustment, physical inventory and consumption — posts back synchronously at the point of scan. The operator’s screen does not advance until Business Central confirms.
4. API Endpoints and Data Mapping
Master data and orders come from Microsoft’s standard API v2.0. Warehouse documents and posting are reached through published page and codeunit web services, or through a small EasyPick extension where you prefer a versioned app. Both routes are configuration on your side, and we tell you which suits your tenant during discovery.
5. Middleware or Integration Platform
Not required. No ESB, no iPaaS, and no Power Automate or Logic Apps component in the posting path. Business Central setup is application registration, an application user with a permission set, and publishing the required web services.
6. Error Handling and Monitoring
Business Central’s own message text is surfaced directly to the operator on the device. Every posting carries a unique EasyPick transaction reference, preventing duplicates and giving each movement a two-way trace. On a timeout EasyPick verifies before it retries. A daily reconciliation compares EasyPick’s transaction log against Business Central to a zero-discrepancy target
7. Testing and Validation
Every endpoint and web service is verified against your own tenant before build. Full end-to-end validation is completed in a sandbox environment before go-live, with a documented test script covering both inbound notification and outbound posting.
Microsoft Dynamics 365 Supply Chain Management
Supported: Dynamics 365 Finance and Supply Chain Management (finance and operations apps), cloud and cloud-hosted.
EasyPick connects directly to D365 with no middleware. The built-in business events framework posts straight to an endpoint you nominate, so there is no Event Grid, Service Bus or Power Automate flow in the path. D365 stays the inventory record. Typical D365 connection time is four to six weeks.
1. Authentication and Security
Microsoft Entra ID OAuth 2.0 service-to-service client credentials against a service account scoped by security role to the sites and warehouses EasyPick operates. Warehouse operators authenticate to EasyPick and never sign in to D365, so they consume no D365 licenses.
2. Master Data Synchronization
Released products, units of measure and barcodes, sites, warehouses and locations, and batch and serial numbers including expiry are read from the OData data entities and cached for instant scanner validation. Refreshed on change, with full nightly reconciliation. EasyPick never creates or amends D365 master data, and does not synchronise customer or vendor master data.
3. Transactional Data Synchronization
Real time in both directions. D365 ships a business event catalog and a data event catalog; events are activated per legal entity and bound to an HTTPS endpoint, and the adapter calls EasyPick directly. EasyPick treats the payload as a notification and re-reads the current record over OData. Every warehouse movement — product receipt, arrival registration, putaway, location transfer, batch disposition, picking registration, packing slip, transfer order ship and receive, production picking, report as finished and counting journal — posts back synchronously at the point of scan. The operator’s screen does not advance until D365 confirms.
4. API Endpoints and Data Mapping
Public data entities are consumed on the OData endpoint and JSON custom services cover the posting logic that entities do not expose. Where a site runs advanced warehouse management, EasyPick drives warehouse work rather than journals; which model applies to each of your sites is settled during discovery, before anything is built.
5. Middleware or Integration Platform
Not required. No ESB, no iPaaS, no Azure integration component in the posting path, and no X++ development for the standard scope. D365 setup is application registration, a service account with security roles, and activating the business events.
6. Error Handling and Monitoring
D365’s own message text is surfaced directly to the operator on the device. Every posting carries a unique EasyPick transaction reference written into the D365 record, preventing duplicates and giving each movement a two-way trace. On a timeout EasyPick verifies before it retries. A daily reconciliation compares EasyPick’s transaction log against D365 to a zero-discrepancy target.
7. Testing and Validation
Every entity and service is verified against your own environment before build. Full end-to-end validation is completed in a sandbox environment before go live, with a documented test script covering both inbound notification and outbound posting.
Epicor Kinetic
Supported: Epicor Kinetic (ERP 11) public cloud, private cloud and on premises, REST API v2.
EasyPick connects directly to Kinetic with no middleware and no database access, which matters on Epicor-hosted SaaS where database access is not available at all. Kinetic stays the inventory record. Typical Kinetic connection time is four to six weeks.
1. Authentication and Security
An API key plus a bearer token, or Azure AD, over HTTPS against a dedicated integration user scoped to the sites and warehouses EasyPick operates. Warehouse operators authenticate to EasyPick and never sign in to Kinetic, so they consume no Kinetic licenses.
2. Master Data Synchronization
Part master, units of measure and barcodes, warehouses and bins, and lots with expiry and status are read through Kinetic’s business objects and cached for instant scanner validation. Refreshed on change, with full nightly reconciliation. EasyPick never creates or amends Kinetic master data, and does not synchronise customer or supplier master data; party detail arrives embedded on the orders EasyPick fetches.
3. Transactional Data Synchronization
Real time in both directions. NetSuite has no native webhook bus, so EasyPick ships a small SuiteApp of user event scripts that post the record type and internal ID the moment a record is committed. Nothing is transformed and no business logic sits in the script, which keeps it inside NetSuite’s governance limits and trivial for your administrator to review. EasyPick then reads the current record. Every warehouse movement — receipt, bin putaway and transfer, location transfer, inventory status change, pick and fulfilment, pack and ship confirm, work order issue and completion, count and adjustment — posts back synchronously at the point of scan. The operator’s screen does not advance until NetSuite confirms.
4. API Endpoints and Data Mapping
Standard Kinetic business objects and BAQs are consumed over OData v2, including Erp.BO.PartSvc, Erp.BO.ReceiptSvc, Erp.BO.InvTransferSvc, Erp.BO.CustShipSvc, Erp.BO.IssueReturnSvc, Erp.BO.JobEntrySvc and Erp.BO.CountCycleSvc. Service and method names are confirmed against your environment using Kinetic’s built-in REST help before build, because the surface moves between releases.
5. Middleware or Integration Platform
Not required. No ESB, no iPaaS, no C# customization, and no screen automation. Kinetic setup is an API key, an integration user, and promotion of the function solution.
6. Error Handling and Monitoring
Kinetic’s own message text surfaces directly to the operator on the device. Every posting carries a unique EasyPick transaction reference written into the Kinetic record, preventing duplicates and giving each movement a two-way trace. On a timeout EasyPick verifies before it retries. A daily reconciliation compares EasyPick’s transaction log against Kinetic to a zero-discrepancy target.
7. Testing and Validation
Every service and field is verified against your own environment before build. Full end-to-end validation is completed in a pilot environment before go-live, with a documented test script covering both inbound notification and outbound posting.
Sage
Integration uses Sage SDK with built-in authentication.
Master records (items, suppliers, customers) are managed through SDK objects.
Purchase and sales transactions flow via SDK interfaces.
SDK mapping ensures correct field alignment with WMS data.
No middleware required, direct SDK calls are used.
SDK error codes are logged with retries for failed operations.
Testing is performed with Sage test company database.
Acumatica
Supported: Acumatica 2022 R1 and later, contract-based REST API with versioned endpoints.
EasyPick connects directly to Acumatica with no middleware. Acumatica stays the inventory record. Because the web service endpoint contract is versioned, an Acumatica upgrade adds fields without breaking existing calls, so the integration does not have to be rebuilt at every release. Typical Acumatica connection time is three to five weeks.
1. Authentication and Security
OAuth 2.0 against a registered connected application, over HTTPS, using a dedicated integration user restricted by role to the warehouses EasyPick operates. Token refresh and concurrent-session limits are handled by EasyPick. Warehouse operators authenticate to EasyPick and never sign in to Acumatica, so they consume no Acumatica licenses.
2. Master Data Synchronization
Stock items and units of measure, barcodes and cross references, warehouses and locations, and lot and serial numbers including expiry are read through the contract-based REST endpoints and cached for instant scanner validation. Refreshed on change, with full nightly reconciliation. EasyPick never creates or amends Acumatica master data, and does not synchronise customer or vendor master data; party detail arrives embedded on the orders EasyPick fetches.
3. Transactional Data Synchronization
Real time in both directions. Acumatica business events trigger push notifications to a webhook when records change, so EasyPick is notified the moment a purchase order, sales order, shipment, transfer or count changes and then reads the current record. Every warehouse movement — purchase receipt, putaway, location transfer, quality hold, pick, pack, ship confirm, issue, adjustment and physical inventory count — posts back synchronously at the point of scan, with the release action invoked in the same call so the document is committed rather than left in a draft state. The operator’s screen does not advance until Acumatica confirms.
4. API Endpoints and Data Mapping
Standard contract-based endpoints are consumed, including Stock Item, Warehouse, Purchase Receipt, Inventory Receipt, Inventory Issue, Inventory Adjustment, Inventory Transfer, Sales Order, Shipment, Physical Inventory Review and Physical Inventory Count. The endpoint $metadata document is read from your own instance before build, so every entity and field is confirmed against the version you actually run rather than a generic specification.
5. Middleware or Integration Platform
Not required. No ESB, no iPaaS and no customization package needed for the standard scope. Acumatica setup is a connected application, an integration user with a role, and the business events that drive the push notifications.
6. Error Handling and Monitoring
Acumatica’s own error text is surfaced directly to the operator on the device. Every posting carries a unique EasyPick transaction reference written into the Acumatica document, preventing duplicates and giving each movement a two-way trace. On a timeout EasyPick verifies before it retries. A daily reconciliation compares EasyPick’s transaction log against Acumatica to a zero-discrepancy target.
7. Testing and Validation
Every entity and field is verified against your own instance before build. Full end-to-end validation is completed in a sandbox instance before go-live, with a documented test script covering both inbound notification and outbound posting.
REST API Platform (Custom Integrations)
Supported: any ERP or host system that exposes an authenticated HTTP API.
Where an ERP is not on this list, EasyPick connects to it the same way it connects to the ones that are. The architecture does not change with the platform: one inventory record, synchronous posting at the point of scan, and no second stock ledger. Connection time depends on the platform's API surface and is quoted after a short discovery.
1. Authentication and Security
OAuth 2.0, mutual TLS or API keys over HTTPS, against a dedicated service account scoped to the warehouses EasyPick operates. Operators authenticate to EasyPick and never to the host system.
2. Master Data Synchronization
Items, units of measure, barcodes, locations, and lot and serial attributes including expiry are read and cached for instant scanner validation, refreshed on change with full nightly reconciliation. EasyPick never creates or amends master data in the host system, and does not synchronise customer or supplier master data.
3. Transactional Data Synchronization
Real time in both directions. Where the host system can push, EasyPick exposes a webhook and uses the notification only as a signal to re-read current state, so duplicate and out-of-order delivery are harmless. Where it cannot, a scheduled delta poll carries the load, and the ingestion pipeline is built event-shaped so adding push later is configuration rather than redesign. Every warehouse movement posts back synchronously at the point of scan, and the operator’s screen does not advance until the host system confirms. If the host system is unreachable, stock affecting work stops rather than queuing against a stock position nobody validated.
4. API Endpoints and Data Mapping
Standard contract-based endpoints are consumed, including Stock Item, Warehouse, Purchase Receipt, Inventory Receipt, Inventory Issue, Inventory Adjustment, Inventory Transfer, Sales Order, Shipment, Physical Inventory Review and Physical Inventory Count. The endpoint $metadata document is read from your own instance before build, so every entity and field is confirmed against the version you actually run rather than a generic specification.
5. Middleware or Integration Platform
Not required. No ESB, no iPaaS and no customization package needed for the standard scope. Acumatica setup is a connected application, an integration user with a role, and the business events that drive the push notifications.
6. Error Handling and Monitoring
Acumatica’s own error text is surfaced directly to the operator on the device. Every posting carries a unique EasyPick transaction reference written into the Acumatica document, preventing duplicates and giving each movement a two-way trace. On a timeout EasyPick verifies before it retries. A daily reconciliation compares EasyPick’s transaction log against Acumatica to a zero-discrepancy target.
7. Testing and Validation
Every entity and field is verified against your own instance before build. Full end-to-end validation is completed in a sandbox instance before go-live, with a documented test script covering both inbound notification and outbound posting.
