.png)
Esker Integration Guide
Integrate Esker Synergy processes with enterprise systems through product-specific REST APIs, selected event notifications, document payloads, and scheduled workflows.
Esker integration options at a glance
Esker provides API-based integration capabilities for selected products and environments, with REST APIs as the primary mechanism to confirm for a tenant. Selected products or business processes may also provide event notifications or outbound callbacks, while document and attachment workflows can involve product-specific file operations. OAuth-based authentication and server-to-server client credentials are relevant for some Esker API environments; scopes, roles, tenant identifiers, and token endpoints require confirmation. Martini can consume Esker REST APIs, expose callback endpoints, run scheduled synchronization workflows, transform JSON and document payloads, apply validation rules, and deliver results to ERP, CRM, procurement, or database systems without direct access to Esker-managed databases.
| Integration point | Supported by Esker? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Limited | Esker provides API-based integration capabilities for selected products and environments, including document, order, customer, and supplier processes. The available resources and operations must be confirmed for the tenant. | Martini can consume Esker REST endpoints, authenticate with environment-specific secrets, transform JSON payloads, apply business rules, and call downstream APIs. |
| Webhooks / outbound callbacks | Limited | Selected Esker products or business processes may provide event notifications for document or workflow events. Universal coverage of objects and state transitions is not confirmed. | Martini can expose an API endpoint, validate callback security, acknowledge events, retrieve the current object when needed, and process the notification asynchronously. |
| File / attachment APIs | Limited | Invoice images, supporting documents, and other attachments are relevant to Esker workflows, but exact upload, download, encoding, and metadata operations depend on the product and tenant. | Martini can process supported file or document payloads, map metadata, route large content appropriately, and send or retrieve files through confirmed Esker endpoints. |
| Authentication | Limited | OAuth-based authentication and client credentials are used in some Esker API environments. API keys or other credentials may exist for selected legacy interfaces but are not universal. | Martini can keep client credentials, tokens, tenant identifiers, and endpoint configuration in environment-specific secrets and use them in workflows. |
| Scheduled synchronization | Yes | Scheduled retrieval is a practical fallback when event delivery is unavailable, including incremental invoice, order, customer, or supplier synchronization. | Martini can trigger workflows on a schedule, persist timestamps or cursors, process pages, and advance checkpoints only after successful handling. |
| Bulk / async / batch APIs | Not confirmed | Enterprise document volume does not by itself confirm public batch APIs, asynchronous jobs, polling, or result files. These capabilities must be verified for the target product. | Martini can orchestrate job submission and polling if Esker exposes those operations, but the workflow should be designed only after the API contract is confirmed. |
| GraphQL APIs | Not confirmed | No official Esker GraphQL API documentation was verified. | Martini should use confirmed Esker REST or other supported interfaces rather than assuming GraphQL availability. |
| SOAP APIs | Not confirmed | Older or product-specific enterprise interfaces may exist, but current Esker SOAP availability was not verified. | Martini can consume SOAP services when Esker confirms a current WSDL and endpoint, but SOAP should not be assumed for a new implementation. |
How Esker exposes data and business events
Esker REST APIs
Esker provides REST-based integration capabilities for selected products and environments. Available resources, operations, base URLs, authentication, and tenant configuration vary by Esker product and should be confirmed before implementation.
Martini implementation pattern
Martini consumes the confirmed Esker REST endpoints from a workflow, stores credentials in environment-specific secrets, maps Esker JSON into canonical models, applies validation and business rules, and writes results to downstream systems. The workflow can also submit transformed invoices, purchase orders, customers, or suppliers to Esker.
Implementation sequence
Esker webhook-style notifications
Selected Esker products or processes may provide event notifications or outbound callbacks. Coverage may be limited to selected document or workflow events, and the notification may contain either a complete object or only an identifier.
Martini implementation pattern
Martini exposes an API endpoint for the callback and starts a webhook-consuming workflow. The workflow validates the sender and any signature or shared secret, acknowledges promptly, retrieves the current Esker object when necessary, and processes the event with duplicate protection.
Implementation sequence
Esker files and attachments
Invoices and order-management processes may involve document images or supporting attachments. Exact upload, download, encoding, file-size, and content-type capabilities depend on the Esker product and tenant.
Martini implementation pattern
Martini receives or retrieves the confirmed document payload, validates content type and metadata, maps the business object separately from the binary content, and transfers the attachment to the target system when supported. Large files and processing status should be handled explicitly.
Implementation sequence
Scheduled Esker synchronization
Scheduled retrieval is a practical integration method when event notifications are unavailable or incomplete. The workflow can synchronize changed Invoices, Purchase orders, Sales orders, Customers, or Suppliers using a timestamp, cursor, or other vendor-supported change marker.
Martini implementation pattern
A Martini scheduler starts the workflow, which retrieves pages of changed Esker objects, processes each item, and persists the synchronization checkpoint only after successful downstream handling. Reconciliation and retry logic protect against records changing during a run.
Implementation sequence
Common Esker integration patterns
Pattern 1: Sync Esker invoices to an ERP
When to use this pattern
Use this pattern when Esker is responsible for invoice capture, validation, or approval and an ERP must receive posting-ready invoice information. It supports scheduled retrieval or selected event notifications and should preserve document identifiers across retries.
Integration direction
Example Mapping
| Esker Field | Canonical Field | Target Field |
|---|---|---|
| invoiceId | externalInvoiceId | EskerReference |
| supplier | supplierReference | Vendor |
| currency | currencyCode | DocumentCurrency |
| invoiceLines | lines | to_Item |
Martini implementation pattern
Martini retrieves or receives Invoices, validates supplier, tax, currency, amount, and line-item data, enriches references when required, and submits the mapped document to the ERP. It stores a stable idempotency key and separates validation, authentication, throttling, and server failures for appropriate retry or manual review.
Martini capabilities used
- workflows
- API consumption
- scheduling
- data mapping
- business rules
- error handling
Pattern 2: Send ERP purchase orders to Esker
When to use this pattern
Use this pattern when an ERP owns approved purchasing documents and Esker manages procurement or supplier-facing processing. The workflow validates that the supplier and approval state are eligible before submission.
Integration direction
Example Mapping
| Esker Field | Canonical Field | Target Field |
|---|---|---|
| purchaseOrderNumber | purchaseOrderId | PurchaseOrderNumber |
| supplierId | supplierReference | Supplier |
| requestedDeliveryDate | deliveryDate | RequestedDeliveryDate |
| lines | orderLines | Items |
Martini implementation pattern
Martini receives or retrieves approved Purchase orders, normalizes dates, currency, tax, supplier identifiers, and line items, then submits the Esker structure through the confirmed API. It records the Esker response, prevents duplicate submission, and routes rejected documents to an exception flow.
Martini capabilities used
- workflows
- API consumption
- data mapping
- validation
- business rules
- retry handling
Pattern 3: Route Esker sales orders to CRM and fulfillment
When to use this pattern
Use this pattern when Esker Order Management is the source for selected Sales orders and Salesforce or a fulfillment platform needs customer, order-line, and status information. Use callbacks only for event types enabled for the tenant; otherwise use incremental retrieval.
Integration direction
Example Mapping
| Esker Field | Canonical Field | Target Field |
|---|---|---|
| customer | customerReference | AccountId |
| orderNumber | salesOrderId | OrderNumber |
| orderLines | lines | OrderItems |
| status | orderStatus | Status |
Martini implementation pattern
Martini receives an eligible callback or retrieves changed Sales orders, enriches customer references where necessary, maps order lines and statuses, and writes the result to Salesforce. Unknown statuses, missing customers, and duplicate events are held for controlled reconciliation rather than silently accepted.
Martini capabilities used
- API exposure
- webhook consumption
- scheduling
- data mapping
- conditional routing
- error handling
Pattern 4: Synchronize Esker suppliers and customers
When to use this pattern
Use this pattern when Esker and an ERP, CRM, procurement, or master-data application share Suppliers or Customers. The design should establish field ownership, external identifiers, and treatment of deactivation or archival states.
Integration direction
Example Mapping
| Esker Field | Canonical Field | Target Field |
|---|---|---|
| supplierId | partyExternalId | externalId |
| supplierName | partyName | companyName |
| customerAddress | billingAddress | address |
| status | partyStatus | isInactive |
Martini implementation pattern
A scheduled Martini workflow retrieves changed objects, compares external identifiers, applies ownership and deactivation rules, and writes only permitted fields to NetSuite. It persists watermarks, records conflicts, and retries transient failures without overwriting successfully synchronized objects.
Martini capabilities used
- scheduling
- API consumption
- data mapping
- business rules
- checkpointing
- reconciliation
Applications commonly integrated with Esker
Esker commonly participates in accounts payable, procurement, order management, and quote-to-cash architectures. The following named applications are realistic integration targets; a specific prebuilt connector is not implied.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| SAP S/4HANA | Exchange suppliers, purchase orders, invoices, accounting information, and payment-related status. | SAP S/4HANA → Martini → Esker | Use REST consumption or scheduled workflows to map ERP documents into Esker structures, validate identifiers and financial values, and return Esker statuses to SAP with idempotent writes. |
| Oracle ERP Cloud | Synchronize supplier invoices, purchase orders, customers, and accounting data. | Oracle ERP Cloud → Martini → Esker | Orchestrate bidirectional API workflows with canonical invoice and order mappings, business validation, checkpointing, and replay of failed documents. |
| Microsoft Dynamics 365 | Exchange customers, sales orders, purchase orders, invoices, and fulfillment status. | Microsoft Dynamics 365 → Martini → Esker | Receive or retrieve changes, normalize customer and order structures, apply status rules, and write accepted documents to the target application with duplicate protection. |
| NetSuite | Synchronize invoices, suppliers, purchase orders, and accounting attributes. | NetSuite → Martini → Esker | Use scheduled or event-driven workflows to transform financial data, preserve external identifiers, and route validation or transport failures for controlled retry. |
| Salesforce | Exchange customers, quotes, sales orders, and customer-service information. | Salesforce → Martini → Esker | Expose or consume APIs for commercial data, map Salesforce identifiers to Esker Customers, Quotes, and Sales orders, and return processing status to Salesforce. |
| Coupa | Exchange requisitions, purchase orders, suppliers, invoices, and procurement status. | Coupa → Martini → Esker | Coordinate procurement document flows, validate supplier and currency data, transform line items, and retain document keys for reconciliation. |
| Workday | Exchange supplier, organizational, invoice, and accounting data where the applicable Esker product supports those objects. | Workday → Martini → Esker | Use explicitly scoped master-data mappings and scheduled workflows, limiting updates to fields owned by each system and recording unsupported object changes. |
| ServiceNow | Route Esker process exceptions, approvals, or document issues into service workflows. | Esker → Martini → ServiceNow | Create or update ServiceNow cases from selected Esker exceptions, map status and severity, and send resolution updates back where the relevant endpoints support it. |
How to build a Esker integration in Martini
Objective
Establish the Esker tenant, product API, endpoint, and authentication configuration required for the integration.
Instructions in Martini
- Confirm the Esker product, environment, tenant identifiers, API resources, and authorization server.
- Configure OAuth client credentials or the confirmed API credential method.
- Store secrets, scopes, roles, and environment-specific URLs outside workflow logic.
- Test HTTPS connectivity and authorization with a least-privilege account.
Objective
Select event-driven, callback, or scheduled execution based on the capabilities enabled for the Esker tenant.
Instructions in Martini
- Use a callback endpoint only for confirmed Esker event types.
- Use a scheduler for incremental retrieval when callbacks are unavailable or incomplete.
- Define the initial synchronization window and checkpoint strategy.
- Document expected delivery, retry, and duplicate behavior.
Objective
Receive or retrieve the Esker object and establish a reliable processing boundary.
Instructions in Martini
- Retrieve the current object when a notification contains only an identifier.
- Process pagination, continuation markers, or vendor-supported timestamps explicitly.
- Preserve Esker identifiers, status values, and source metadata.
- Record the input and correlation identifier for reconciliation.
Objective
Implement the end-to-end Martini workflow that validates, transforms, routes, and persists each business object.
Instructions in Martini
- Separate transport, authentication, validation, and business failures.
- Use conditional routing for object type, status, and target-system decisions.
- Use reusable workflow logic for common authentication, mapping, and error handling.
- Keep long-running or attachment processing separate when appropriate.
Objective
Transform Esker payloads into a canonical or target-specific model without losing financial and document semantics.
Instructions in Martini
- Map actual Esker objects such as Invoices, Purchase orders, Sales orders, Customers, and Suppliers.
- Preserve decimal precision, currency codes, dates, time zones, tax values, and external identifiers.
- Validate required fields, enumerations, supplier or customer references, and line items.
- Handle attachments separately from their business-object metadata.
Objective
Apply business ownership, status, approval, duplicate, and eligibility rules before writing data.
Instructions in Martini
- Treat Esker status transitions explicitly rather than inferring completion from HTTP success.
- Use stable idempotency keys for documents and submissions.
- Route unknown statuses, missing references, and validation failures to an exception path.
- Prevent updates to fields owned by the other system.
Common Esker data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Invoices | Supplier invoices, invoice data, validation status, approval status, and payment-related information. | SAP S/4HANA, Oracle ERP Cloud, Microsoft Dynamics 365, NetSuite, Coupa | Retrieve or receive invoice data, validate supplier, tax, currency, and line values, map to a canonical invoice model, and preserve Esker identifiers for idempotency. |
| Purchase orders | Purchasing documents used in procure-to-pay processes. | SAP S/4HANA, Oracle ERP Cloud, Microsoft Dynamics 365, NetSuite, Coupa | Transform header, supplier, delivery, tax, and line-item data, apply approval rules, and submit or synchronize only after validation. |
| Sales orders | Customer orders processed through Esker Order Management. | Salesforce, Microsoft Dynamics 365, SAP S/4HANA, fulfillment platforms | Use event notifications where available or incremental retrieval, map customers and order lines, and route status changes to downstream systems. |
| Customers | Customer accounts and quote-to-cash or order-management information. | Salesforce, Microsoft Dynamics 365, SAP S/4HANA, Oracle ERP Cloud | Define system-of-record ownership, reconcile external identifiers, normalize addresses and account states, and avoid overwriting fields owned elsewhere. |
| Suppliers | Supplier records used in accounts payable and procurement processes. | SAP S/4HANA, Oracle ERP Cloud, NetSuite, Coupa, Workday | Synchronize approved supplier attributes, validate identifiers and status values, and handle deactivation or archival states explicitly. |
| Quotes | Quotations and quote-related information in quote-to-cash workflows. | Salesforce, Microsoft Dynamics 365, ERP platforms | Map quote headers, customer references, dates, currency, and lines, then apply commercial validation before downstream submission. |
Authentication and security considerations
Tenant-specific authentication
Esker authentication varies by product, API, deployment, and tenant. OAuth 2.0 and client credentials are relevant for some API environments; scopes, roles, token endpoints, and tenant identifiers must be confirmed.
Secrets and transport
Martini should store Esker client credentials, tokens, tenant settings, and endpoint configuration as environment-specific secrets. API communication should use HTTPS and least-privilege permissions.
Callback protection
For enabled callbacks, validate the sender, HTTPS connection, signature or shared secret, timestamp, and event identifier. Confirm Esker’s delivery and retry behavior before relying on the callback as the system of record.
Operational considerations for Esker integrations
Pagination and rate limits
Confirm whether Esker uses page, offset, cursor, or continuation-token pagination, as well as per-tenant limits, concurrency constraints, and document-processing quotas. Use controlled backoff for throttling and transient server responses.
Idempotency and status
Use stable Esker document or external identifiers to prevent duplicate invoices and orders. Map status transitions explicitly and do not treat HTTP success as proof of business completion.
Schema and financial data
Use explicit mappings and monitor required fields, enum changes, endpoint versions, currency precision, tax calculations, dates, and time zones. Test representative invoices, orders, approvals, exceptions, and attachments.
Reconciliation
Persist checkpoints only after successful processing, retain failed identifiers and responses, and separate validation failures from authentication, transport, throttling, and server errors so records can be replayed safely.
Why use Martini instead of scripts or point-to-point integrations?
Reusable orchestration
Martini coordinates Esker API calls, callback handling, scheduled retrieval, transformations, target-system writes, and exception paths in maintainable workflows rather than isolated scripts.
Controlled data movement
Explicit mappings, validation, business rules, idempotency keys, checkpoints, and environment-specific secrets provide a governed approach to financial and document integrations.
Adaptable integration design
Because Esker capabilities vary by product and tenant, Martini can combine confirmed REST APIs, selected callbacks, files, and scheduled synchronization without assuming a universal connector or direct database access.
Frequently asked questions
Esker can be integrated through REST APIs available for selected products and environments, selected event notifications or outbound callbacks, supported document or attachment operations, and scheduled incremental synchronization. The exact API resources, authentication, event coverage, and tenant configuration must be confirmed with Esker.
Yes. Martini can consume confirmed Esker REST APIs, expose an API endpoint for supported Esker callbacks, run scheduled synchronization workflows, transform Esker JSON or document payloads, and deliver results to ERP, CRM, procurement, or other enterprise systems.
No dedicated Esker connector is required. Martini can use Esker’s confirmed native integration mechanisms, including REST APIs, supported callback events, files or document payloads, authentication methods, and scheduled workflows. A specific native Martini connector was not verified.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Esker. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Esker, cloud infrastructure providers, or other third-party systems based on subscription, usage, and deployment model.
Confirm the Esker product-specific REST API first, because REST is the primary documented integration direction in the supplied research. Use selected callbacks or event notifications when enabled, files or attachments when explicitly supported, and scheduled retrieval as a dependable fallback. GraphQL is not confirmed and current SOAP availability was not verified.
Event-oriented notifications or outbound callbacks may be available for selected Esker products and business processes, but universal webhook coverage is not confirmed. Verify event types, delivery format, callback authentication, retry behavior, signatures, duplicate delivery, and whether the payload contains the full object or only an identifier.
Martini can retrieve changed Esker objects on a schedule using a vendor-supported timestamp, cursor, or continuation marker, or process selected callback events. It can paginate results, map objects into target models, persist checkpoints after successful processing, and reconcile failed or changed records.
Martini can map Esker Invoices, Purchase orders, Sales orders, Customers, Suppliers, and Quotes into canonical or target-specific models, while applying validation and business rules. Workflows can distinguish validation, authentication, throttling, transport, and server errors, retry transient failures, and use stable document or external identifiers to prevent duplicates.
Related Martini documentation
Workflows
Data
Plan your Esker integration with Martini
Use Martini to design a governed Esker integration around confirmed APIs, callbacks, document flows, authentication, mappings, and synchronization requirements.