Ellipse Gradient for Header

Epicor Eclipse Integration Guide

Epicor Eclipse integrates with enterprise systems primarily through deployment-specific REST APIs, supported authentication services, scheduled workflows, and customer-configured exchange mechanisms.

Epicor Eclipse integration options at a glance

Epicor positions REST APIs as an integration mechanism across its ERP portfolio, although the resources, operations, authentication scheme, and write support available in a particular Eclipse deployment must be verified. Martini can consume exposed Eclipse REST APIs, authenticate through the configured gateway or integration service, and orchestrate workflows for Customers, Vendors, Products, Inventory, Sales Orders, Purchase Orders, and Invoices. Scheduled workflows can support incremental synchronization where reliable change markers exist. Webhooks, outbound callbacks, bulk services, file exchange, EDI, and database access should be treated as deployment-specific rather than assumed capabilities. Martini can also expose a controlled API façade for downstream applications.

Integration pointSupported by Epicor Eclipse?Common use casesHow Martini supports it
REST APIsLimitedEpicor documents REST APIs across its ERP portfolio. In Eclipse, they may be used to read or write Customers, Vendors, Products, Inventory, Sales Orders, Purchase Orders, and Invoices, subject to deployment-specific endpoint coverage.Martini can consume the exposed REST endpoints, handle authentication and pagination, map payloads, orchestrate multi-step workflows, and expose a normalized REST API for downstream applications.
AuthenticationLimitedEclipse API authentication may be configured through an API gateway or integration service using credentials, keys, or another deployment-specific scheme. Exact OAuth, JWT, or scope support must be confirmed.Martini can keep environment-specific credentials or tokens in secrets and apply the confirmed authentication configuration to API workflows without embedding credentials in mappings or payloads.
Scheduled synchronizationYesScheduled extraction is a practical option for Products, Inventory, Customers, Invoices, and other resources when webhook or event coverage is not confirmed. Incremental behavior depends on available change markers.Martini can trigger workflows on a schedule, apply date-range or checkpoint logic, throttle requests, and resume controlled synchronization after failures.
Webhooks / outbound callbacksNot confirmedNo general-purpose Eclipse webhook framework or complete event subscription model was confirmed. Customer-specific callbacks or event services may exist and require separate validation.If the deployment exposes a supported callback endpoint, Martini can receive and process it; otherwise, scheduled API retrieval is the safer design assumption.
Bulk / asynchronous / batch APIsNot confirmedNo standardized public Eclipse bulk or asynchronous API was confirmed. Large loads may use pagination, scheduled queries, customer-specific batch services, files, or EDI where configured.Martini can implement checkpointed, throttled workflows around confirmed paging or batch services and separate migration processing from transactional flows.
File / attachment exchangeNot confirmedDistribution processes may involve documents, EDI, SFTP, or import/export services, but a general-purpose public Eclipse attachment API was not verified.Martini can process files or approved exchange endpoints when the customer deployment provides them, while validating file schemas and associating documents with Eclipse identifiers.
Database / analytics accessNot confirmedDirect database access is deployment-specific and is not the default transactional integration strategy. Read-only reporting or reconciliation access may be considered only after authorization.Martini can connect to supported databases where explicitly approved, but API-based integration should be preferred for writes and business-rule-driven operations.
GraphQL APIsNot confirmedNo official Eclipse GraphQL API documentation was confirmed.Martini can consume GraphQL generally, but an Eclipse GraphQL integration should not be designed until the target deployment documents such an endpoint.

How Epicor Eclipse exposes data and business events

Epicor Eclipse REST APIs

Epicor publicly positions REST APIs as an integration mechanism across its ERP portfolio. Eclipse-specific resources, operations, pagination behavior, write support, and custom fields must be confirmed for the target installation.

Martini implementation pattern

Martini implementation pattern: Martini authenticates to the customer-approved Eclipse API, retrieves or submits the required resource, validates the response, maps it to a canonical or target schema, and orchestrates related calls such as customer validation, inventory lookup, order creation, or status retrieval.

Implementation sequence

Authenticate using the deployment-approved Eclipse API configuration
Receive an API request or start a scheduled synchronization
Retrieve or submit the required Eclipse resource
Validate identifiers, required fields, and business conditions
Map and transform the payload for the target system
Apply idempotency, status, and routing rules before writing changes

Epicor Eclipse scheduled synchronization

Scheduled synchronization is a practical design for Products, Inventory, Customers, Invoices, and other resources when general-purpose webhooks or event subscriptions are not confirmed. Incremental extraction depends on reliable filtering and change markers.

Martini implementation pattern

Martini implementation pattern: a scheduled workflow reads bounded Eclipse API pages, uses a modified-since value or integration checkpoint when available, transforms each object, writes it to the target, and records successful progress. If Eclipse lacks a reliable change marker, the workflow can use controlled reconciliation windows.

Implementation sequence

Start the scheduled synchronization workflow
Load the last successful checkpoint and extraction window
Retrieve filtered and paginated Eclipse resources
Map and validate each object against the target model
Write valid objects and record correlation identifiers
Persist the checkpoint and route failures for retry or review

Epicor Eclipse callbacks and file exchange

No general-purpose Eclipse webhook framework or complete event model was confirmed. Some deployments may provide outbound callbacks, event services, EDI, SFTP, or customer-specific import and export mechanisms that must be assessed separately.

Martini implementation pattern

Martini implementation pattern: where the customer provides a supported callback or file exchange, Martini receives the message or file, validates its source and structure, transforms it into the required workflow input, and routes it to Eclipse or another system. Unsupported or undocumented mechanisms should not be assumed.

Implementation sequence

Confirm the deployment-specific callback or file contract
Receive the callback or collect the approved file
Validate authentication, schema, identifiers, and duplicate status
Transform the input into the Eclipse or canonical model
Invoke the supported Eclipse operation or downstream API
Record processing status and quarantine invalid inputs

Common Epicor Eclipse integration patterns

Pattern 1: Orchestrate commerce orders into Eclipse

When to use this pattern

Use this pattern when Shopify or another commerce application must submit orders to Eclipse while customer, product, inventory, warehouse, pricing, tax, and shipping rules are applied before order creation. It is appropriate when the Eclipse deployment exposes supported Sales Order operations.

Integration direction
Shopify
Martini
Epicor Eclipse
Example Mapping
Epicor Eclipse FieldCanonical FieldTarget Field
order.idexternalOrderIdSales Order correlation ID
customer.emailcustomerReferenceCustomer identifier
lineItems[].skuproductCodeSales Order line product
lineItems[].quantityorderedQuantitySales Order line quantity
Martini implementation pattern

Martini receives the commerce order, searches or matches the Eclipse Customer, validates Products and Inventory, applies warehouse and pricing rules, and creates a Sales Order where supported. It stores the source order ID and Eclipse document number, treats ambiguous timeouts as reconciliation cases, and retries only transient failures.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • business rules
  • validation
  • error handling

Pattern 2: Synchronize Products and Inventory to commerce

When to use this pattern

Use this pattern when a storefront or downstream application needs current product descriptions, identifiers, units, prices, and warehouse availability from Eclipse. Scheduled polling is the safer default because general-purpose Eclipse events were not confirmed.

Integration direction
Epicor Eclipse
Martini
Shopify
Example Mapping
Epicor Eclipse FieldCanonical FieldTarget Field
Product.productCodeskuShopify variant SKU
Product.descriptionproductDescriptionShopify product description
Product.unitOfMeasureunitOfMeasureShopify metafield
Inventory.availableQuantityavailableToSellShopify inventory quantity
Martini implementation pattern

A scheduled Martini workflow retrieves bounded Product and Inventory pages, uses a confirmed modified-since filter or checkpoint when available, normalizes units and quantities, and publishes changes to Shopify. It throttles requests, records the last successful page or object, and routes invalid product mappings to an exception process.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • pagination orchestration
  • data mapping
  • checkpointing
  • retry handling

Pattern 3: Reconcile Eclipse invoices with finance

When to use this pattern

Use this pattern when Invoices and related Sales Orders from Eclipse must be delivered to NetSuite, Microsoft Dynamics 365, or another financial process for billing visibility and reconciliation.

Integration direction
Epicor Eclipse
Martini
NetSuite
Example Mapping
Epicor Eclipse FieldCanonical FieldTarget Field
Invoice.invoiceNumberdocumentNumberNetSuite invoice number
Invoice.customerCodecustomerReferenceNetSuite customer
Invoice.totalgrossAmountNetSuite total
Invoice.statusdocumentStatusNetSuite transaction status
Martini implementation pattern

Martini retrieves Invoices and related Sales Order information, validates customer references and monetary precision, maps tax and status values, and sends the result to the finance application. It preserves Eclipse identifiers, detects duplicate documents, and places rejected or incomplete invoices into a reconciliation queue rather than silently retrying business errors.

Martini capabilities used
  • workflows
  • API consumption
  • data transformation
  • validation
  • business rules
  • error handling

Pattern 4: Route procurement and supplier updates

When to use this pattern

Use this pattern when Vendors, Purchase Orders, and replenishment information from Eclipse must be shared with a procurement, supplier, or analytics application. The flow should distinguish approved writes from reporting-only synchronization.

Integration direction
Epicor Eclipse
Martini
Microsoft Dynamics 365
Example Mapping
Epicor Eclipse FieldCanonical FieldTarget Field
Vendor.vendorCodesupplierReferenceDynamics supplier account
PurchaseOrder.purchaseOrderNumberpurchaseOrderNumberDynamics purchase order
PurchaseOrder.expectedDateexpectedDeliveryDateDynamics expected receipt date
PurchaseOrder.statusprocurementStatusDynamics order status
Martini implementation pattern

Martini reads supported Vendors and Purchase Orders, applies supplier and warehouse routing rules, transforms dates and statuses, and writes only operations permitted by the target contracts. Checkpoints support restartable extraction, while supplier mismatches, invalid dates, and rejected writes are reported separately from transient API failures.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • business rules
  • checkpointing
  • monitoring

Applications commonly integrated with Epicor Eclipse

Epicor Eclipse commonly participates in distribution architectures that connect ERP data with commerce, sales, finance, logistics, service, tax, and analytics applications. The following are practical integration targets; availability of specific Eclipse operations depends on the customer deployment and supported API surface.

Application Scenario Direction Martini Pattern
Shopify Publish Products and Inventory to an online storefront and submit web orders to Eclipse as Sales Orders. Shopify → Martini → Epicor Eclipse Martini receives or polls Shopify orders, validates Customers and Products in Eclipse, checks Inventory, applies warehouse and pricing rules, creates a Sales Order where supported, and returns the Eclipse identifier and status. Correlation keys and reconciliation prevent duplicate order creation.
Salesforce Give sales teams visibility into Customers, Contacts, Sales Orders, invoices, and account status while sending approved customer or order data back to Eclipse. Epicor Eclipse → Martini → Salesforce A scheduled Martini workflow retrieves changed Eclipse Customers and Sales Orders, maps identifiers and status fields to Salesforce objects, applies matching rules, and records correlation identifiers. A reverse flow can validate and route approved customer or order updates to Eclipse where supported.
NetSuite Exchange Customers, Vendors, Sales Orders, Purchase Orders, and Invoices when Eclipse and NetSuite coexist in a broader operational or financial architecture. Epicor Eclipse → Martini → NetSuite Martini normalizes Eclipse and NetSuite payloads through a canonical model, applies ownership and status rules, routes supported creates or updates, and isolates validation failures from retryable transport errors. Reconciliation checkpoints preserve document numbers and totals.
Microsoft Dynamics 365 Synchronize customer, product, order, inventory, and financial information between distribution operations and Microsoft business applications. Epicor Eclipse → Martini → Microsoft Dynamics 365 Martini consumes Eclipse REST resources on a schedule or through an approved inbound trigger, transforms product, customer, inventory, and order fields, and invokes Microsoft APIs. Optional reverse processing is governed by source-of-truth and duplicate-prevention rules.
ServiceNow Create incidents or service requests for order, inventory, API, and fulfillment exceptions that require operational follow-up. Epicor Eclipse → Martini → ServiceNow Martini classifies Eclipse workflow failures and business exceptions, enriches them with correlation and document identifiers, and creates ServiceNow records. Status updates can be routed back to an integration queue or Eclipse only where an approved operation exists.
Avalara Exchange transaction and tax data for sales-tax calculation or reconciliation associated with eligible Eclipse orders and invoices. Epicor Eclipse → Martini → Avalara Martini maps customer, address, line, amount, and jurisdiction data from the Eclipse order or invoice, calls the applicable Avalara API, validates the response, and returns tax results to the controlled Eclipse workflow where supported. Failed tax calls are held for retry or review.
UPS Obtain shipping rates, labels, tracking data, or shipment status associated with Eclipse fulfillment processes. Epicor Eclipse → Martini → UPS Martini retrieves eligible fulfillment data from Eclipse, transforms warehouse and shipment details for UPS, and routes tracking responses back to downstream systems or Eclipse where supported. Shipment identifiers and retry-safe status updates are retained for reconciliation.
Power BI Deliver curated Eclipse sales, inventory, purchasing, and invoice information for reporting and operational analytics. Epicor Eclipse → Martini → Power BI A scheduled Martini workflow extracts supported Eclipse resources with filtering and checkpoints, normalizes data types and business statuses, and publishes curated payloads to Power BI or an intermediate data store. Failed batches can resume from the last successful checkpoint.

How to build a Epicor Eclipse integration in Martini

Objective

Establish the Eclipse API connection and confirm the endpoint, deployment version, exposed resources, service account, permissions, and authentication scheme before building workflow logic.

Instructions in Martini

  • Confirm the Eclipse base URL and available API resources
  • Obtain the deployment-approved credentials, keys, or tokens
  • Store authentication material in environment-specific Martini secrets
  • Verify read and write permissions separately

Objective

Select a trigger based on the confirmed Eclipse capabilities and business latency requirements, without assuming general-purpose webhooks or event subscriptions.

Instructions in Martini

  • Use a scheduled trigger for polling and incremental synchronization
  • Use an API trigger for inbound order or request orchestration
  • Use a webhook or callback trigger only when the deployment documents and exposes one
  • Define extraction windows and checkpoints for scheduled flows

Objective

Retrieve Customers, Vendors, Products, Inventory, Sales Orders, Purchase Orders, or Invoices through supported Eclipse operations and account for response limits.

Instructions in Martini

  • Use confirmed filters, sorting, and pagination
  • Request only the fields required by the integration
  • Preserve Eclipse identifiers and source timestamps
  • Record page or checkpoint progress for restartable processing

Objective

Coordinate dependent operations such as customer matching, inventory lookup, tax calculation, order submission, and status retrieval in a maintainable Martini workflow.

Instructions in Martini

  • Separate validation, enrichment, writes, and notifications into clear stages
  • Apply conditional routing for business and transport outcomes
  • Use correlation identifiers across every API call
  • Keep transactional and bulk synchronization flows separate

Objective

Convert Eclipse payloads into canonical or target application models while handling distribution-specific identifiers, units, amounts, statuses, and optional custom fields.

Instructions in Martini

  • Map Product codes, aliases, and units of measure explicitly
  • Normalize currency, tax, decimal precision, and date values
  • Handle optional or customer-specific fields defensively
  • Validate required fields before target writes

Objective

Reflect customer matching, credit, availability, warehouse, pricing, supplier, and document-status rules without assuming that API acceptance means the transaction is released or fulfilled.

Instructions in Martini

  • Define source-of-truth ownership for each object
  • Reject ambiguous Customer, Product, and Vendor matches
  • Use deterministic idempotency keys for orders and invoices
  • Track intermediate Eclipse statuses explicitly

Common Epicor Eclipse data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
CustomersSynchronize customer accounts, addresses, contacts, credit information, and account status.Salesforce, Shopify, Microsoft Dynamics 365, tax services, analytics platformsMartini retrieves or receives supported Customer payloads, applies matching and validation rules, maps identifiers and addresses, and preserves Eclipse correlation data for reconciliation.
VendorsExchange supplier records, supplier addresses, purchasing terms, and vendor status.NetSuite, Microsoft Dynamics 365, procurement applications, analytics platformsMartini normalizes supplier identifiers and terms, validates required fields, routes approved changes, and separates duplicate or ambiguous matches for review.
ProductsSynchronize product identifiers, descriptions, units of measure, pricing, and product status.Shopify, Salesforce, Microsoft Dynamics 365, analytics platformsMartini maps product codes, aliases, units, prices, and optional fields, then publishes or writes supported updates with schema validation.
InventoryExchange stock availability, warehouse quantities, allocations, and replenishment information.Shopify, commerce applications, logistics systems, Power BIMartini retrieves Inventory using supported filters or checkpoints, transforms warehouse and quantity data, and applies throttling and reconciliation for large extracts.
Sales OrdersProcess customer orders, lines, quantities, prices, shipping details, and order status.Shopify, Salesforce, Avalara, UPS, financial systemsMartini validates Customers and Products, checks Inventory, applies pricing and fulfillment rules, creates or updates supported orders, and uses external order IDs for idempotency.
Purchase OrdersSynchronize replenishment or supplier orders, lines, expected dates, and purchasing status.NetSuite, Microsoft Dynamics 365, procurement applications, analytics platformsMartini maps supplier and line data, applies warehouse and expected-date rules, routes supported writes, and records status transitions and failed validations.

Authentication and security considerations

Deployment-specific authentication

Eclipse authentication may be configured through an API gateway or integration service using credentials, keys, or another environment-specific mechanism. OAuth 2.0, JWT, and scopes should not be assumed without confirmation from the target deployment.

Credential protection

  • Use HTTPS for API communication.
  • Store credentials, keys, or tokens in environment-specific Martini secrets.
  • Use a dedicated integration identity with only the permissions required for the workflow.
  • Do not place credentials in payloads, mappings, source-controlled scripts, or hard-coded workflow values.

Authorization

Confirm resource-level permissions, read and write access, and whether Eclipse roles, service accounts, or gateway policies govern each operation.

Operational considerations for Epicor Eclipse integrations

API variability

Eclipse installations can differ by version, hosting model, enabled services, customizations, and API exposure. Confirm base URLs, resources, operations, custom fields, pagination, filtering, and write behavior before implementation.

Volume and synchronization

  • Use pagination and bounded extraction windows for Products, Inventory, Customers, and Invoices.
  • Prefer reliable modified-since values, sequence markers, or checkpoints for incremental synchronization.
  • Use controlled batch workflows for large historical migrations.
  • Limit concurrency and honor HTTP 429 or vendor-specific throttling responses.

Reliability and data integrity

  • Use idempotency keys and source identifiers for Sales Orders and Invoices.
  • Reconcile ambiguous responses before retrying writes.
  • Separate validation and business-rule failures from transient transport errors.
  • Preserve currency precision, tax treatment, units of measure, warehouse identifiers, time zones, and document statuses.

Testing and change management

Test against representative Eclipse data and customer-specific customizations. Version mappings, validate optional fields, monitor schema changes, and verify that API acceptance does not necessarily indicate order release or fulfillment.

Database caution

Direct database access should not be the default transactional strategy. Consider read-only reporting or reconciliation access only when explicitly authorized and compatible with support and upgrade requirements.

Why use Martini instead of scripts or point-to-point integrations?

Centralized orchestration

Martini coordinates Eclipse API calls, validation, enrichment, target writes, status handling, and exception routing in workflows rather than scattering logic across scripts or point-to-point integrations.

Reusable transformation logic

Mappings and reusable workflow assets can normalize Eclipse Customers, Products, Inventory, orders, purchasing data, and Invoices for multiple downstream applications while preserving source identifiers.

Operational resilience

Martini provides a structured place to implement checkpoints, idempotency, controlled retries, throttling, validation, logging, and reconciliation for deployment-specific Eclipse behavior.

Stable API boundaries

Martini can expose controlled REST APIs that shield downstream applications from Eclipse-specific schemas and customizations, allowing enterprise consumers to use a consistent contract.

Maintainable enterprise integration

Compared with isolated scripts, workflow-based integration makes authentication, business rules, transformations, monitoring, and error handling easier to govern and update as the Eclipse environment changes.

Frequently asked questions

How can Epicor Eclipse be integrated with enterprise systems?

Epicor Eclipse can be integrated primarily through REST APIs where the customer deployment exposes the required resources and operations. Common flows include synchronizing Customers, Vendors, Products, Inventory, Sales Orders, Purchase Orders, and Invoices, using scheduled retrieval when webhooks or event subscriptions are not confirmed. Some deployments may also provide approved callbacks, files, EDI, or customer-specific services.

Can Martini integrate with Epicor Eclipse?

Yes. Martini can consume an Eclipse REST API where available, authenticate using the deployment-approved method, orchestrate multi-step workflows, map and transform Eclipse payloads, and expose APIs for downstream applications. Exact endpoint coverage, authentication, pagination, and write support must be confirmed for the target Eclipse installation.

Do I need a connector to integrate Epicor Eclipse with Martini?

No. A dedicated Epicor Eclipse connector is not required. Martini can integrate using Eclipse's confirmed native integration mechanisms, principally supported REST APIs and any deployment-specific callbacks, files, or other approved endpoints. A native Martini connector was not documented in the supplied research.

Is there any extra Lonti cost to integrate Epicor Eclipse with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Epicor Eclipse. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from Epicor, infrastructure providers, or other third-party systems depending on subscriptions, usage, and deployment model.

Which Epicor Eclipse integration methods should architects use?

REST APIs are the primary documented direction, but Eclipse-specific resources and operations must be verified. Scheduled API synchronization is a practical design for Products, Inventory, Customers, and Invoices. GraphQL and current SOAP APIs were not confirmed, and bulk, file, callback, and database mechanisms should be treated as deployment-specific.

Does Epicor Eclipse provide webhooks or event notifications?

A general-purpose Eclipse webhook framework or complete event-subscription model was not confirmed. A particular deployment may expose outbound callbacks, event services, or extensions, but coverage for Customers, Products, Inventory, Sales Orders, Purchase Orders, and Invoices must be verified. Without confirmed events, scheduled polling or incremental API retrieval is the safer assumption.

How should Epicor Eclipse data synchronization and transformation be implemented?

Use supported pagination, filtering, and a reliable modified-since value or other change marker where available. Martini can map Eclipse objects into canonical or target schemas, normalize units, amounts, dates, statuses, and identifiers, and maintain checkpoints. If no reliable change marker exists, use bounded reconciliation windows and preserve source identifiers for comparison.

How should errors, retries, and duplicate Eclipse orders be handled?

Separate authentication, authorization, validation, business-rule, duplicate, rate-limit, timeout, and server errors. Retry only bounded transient failures with backoff, and reconcile ambiguous write responses before retrying. For Sales Orders and Invoices, use source-system identifiers and deterministic idempotency keys, search before creating where supported, and retain Eclipse document numbers and correlation IDs.

Related Martini documentation

APIs

Workflows

Data

Security

Operations

Integrate Epicor Eclipse with Martini

Use Martini to connect supported Epicor Eclipse APIs and deployment-specific exchange mechanisms to enterprise applications through governed workflows, reusable mappings, secure configuration, and operational controls.

EXPLORE MARTINI
BOOK A DEMO