.png)
Priority Software Integration Guide
Integrate Priority ERP with enterprise applications through its REST APIs, authenticated web services, scheduled workflows, and deployment-specific callbacks.
Priority Software integration options at a glance
Priority ERP is commonly integrated through Priority’s REST APIs and API-oriented web services. Martini can consume these APIs from workflows, transform Customers, Suppliers, Items, Sales Orders, Purchase Orders, and Invoices, and expose normalized REST APIs for downstream applications. Priority authentication depends on the deployment and may use a Priority user or API account, Basic Authentication, a session, a token, or another environment-specific arrangement that must be confirmed. Selected deployments may provide callbacks or event notifications, but universal webhook coverage is not verified. Scheduled polling and incremental queries are therefore important alternatives. Legacy SOAP or other web services, file exchange, and bulk processing should be validated for the target installation.
| Integration point | Supported by Priority Software? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Priority ERP REST APIs can be used to read and update Customers, Suppliers, Items, Sales Orders, Purchase Orders, and Invoices, and to retrieve transaction status. | Martini can consume Priority REST endpoints from workflows, map payloads, apply validation and business rules, and expose normalized APIs. |
| SOAP APIs | Legacy | Priority has historically supported web-service integration patterns, but current SOAP coverage and suitability for new integrations must be confirmed for the target deployment. | Martini can consume SOAP services when the applicable Priority version and interface are confirmed, including the required configuration and error handling. |
| Webhooks / outbound callbacks | Limited | Selected Priority processes or deployments may provide callbacks or event notifications, but universal webhook coverage for all business objects was not verified. | Martini can expose an API or webhook workflow to receive confirmed callbacks and route them into downstream processing; otherwise scheduled polling can be used. |
| Bulk / async / batch APIs | Not confirmed | Multiple-record, asynchronous, and long-running export behavior must be confirmed for the relevant Priority resources and environment. | Martini can orchestrate bounded batches and scheduled workflows when the Priority API supports them, but it does not assume bulk behavior. |
| File / attachment APIs | Not confirmed | Priority business processes may involve documents and files, but a general public attachment API or standard file-transfer pattern was not verified. | Martini can process files when the customer confirms a supported Priority endpoint or exchange mechanism; the implementation should validate formats and ownership. |
| Authentication | Limited | Priority API access requires credentials associated with a Priority user or API account, with the exact Basic Authentication, session, token, or other flow depending on deployment. | Martini can store credentials and environment-specific endpoint settings in protected configuration and secrets and apply the confirmed authentication arrangement. |
| Database / analytics access | Not confirmed | Direct database access may be possible in some deployments but is not a generally verified public Priority integration contract and is not the default boundary. | Martini can connect to supported databases when separately provisioned, but Priority application APIs should be preferred for business transactions and upgradeability. |
How Priority Software exposes data and business events
Priority REST APIs
Priority ERP’s primary documented integration mechanism is its REST API and related API-oriented web services. The APIs can expose business objects such as Customers, Suppliers, Items, Sales Orders, Purchase Orders, and Invoices, subject to version, module, localization, and permission differences.
Martini implementation pattern
Martini implementation pattern: configure the confirmed Priority endpoint and authentication in protected settings, invoke it from a workflow, validate the response, map it to a canonical model, apply business rules, and write the result to the target system. Store source and target identifiers for idempotency and reconciliation.
Implementation sequence
Priority callbacks and event notifications
A universal Priority webhook framework was not verified, but selected deployments or processes may provide callbacks or event notifications. Coverage must be confirmed for each business object and event.
Martini implementation pattern
Martini implementation pattern: expose a controlled API or webhook workflow only for confirmed Priority callbacks, authenticate and validate the request, retrieve the current Priority resource when necessary, and use a correlation key to prevent duplicate processing. If callbacks are unavailable, use scheduled polling instead.
Implementation sequence
Scheduled Priority synchronization
Scheduled polling is an important integration option when Priority does not provide the required event notification. Incremental queries, modified-date filters, pagination, and change sequences must be confirmed for the target resources.
Martini implementation pattern
Martini implementation pattern: start a scheduled workflow, retrieve data in bounded pages, transform each object, write successful results, and persist a checkpoint or reconciliation state. The workflow should avoid full-collection reloads when Priority supports incremental filtering.
Implementation sequence
Priority legacy web services
Priority has historically supported SOAP and other web-service patterns, but the current public evidence is insufficient to classify SOAP as a recommended general-purpose mechanism. The specific Priority version and deployment must be validated.
Martini implementation pattern
Martini implementation pattern: consume the confirmed legacy service only when the required resource is unavailable through the preferred REST API, isolate the legacy interface behind a reusable workflow, transform XML or service-specific structures, and preserve detailed fault information.
Implementation sequence
Common Priority Software integration patterns
Pattern 1: Sync Priority customers and items to commerce
When to use this pattern
Use this pattern when Priority owns customer or product master data and a commerce platform needs current catalog, availability, or customer attributes. Incremental filtering should be used when supported, with scheduled reconciliation as a safety net.
Integration direction
Example Mapping
| Priority Software Field | Canonical Field | Target Field |
|---|---|---|
| Customer.Code | customer.externalId | Shopify customer metafield |
| Item.Code | product.sku | Shopify product variant SKU |
| Item.Description | product.name | Shopify product title |
| Item.Availability | inventory.availableQuantity | Shopify inventory quantity |
Martini implementation pattern
A scheduled Martini workflow retrieves changed Customers and Items from Priority, validates required identifiers, maps localized descriptions and units, applies field-ownership rules, and updates Shopify. It records the last successful checkpoint, uses deterministic keys for idempotency, and routes validation or transport failures to retry and reconciliation handling.
Martini capabilities used
- scheduled triggers
- API consumption
- data mapping
- validation
- business rules
- error handling
Pattern 2: Create Priority sales orders from commerce
When to use this pattern
Use this pattern when Shopify, Adobe Commerce, or WooCommerce is the order capture system and Priority is the ERP system of record for fulfillment or financial processing.
Integration direction
Example Mapping
| Priority Software Field | Canonical Field | Target Field |
|---|---|---|
| order.id | salesOrder.externalId | Priority Sales Order reference |
| customer.email | customer.email | Priority Customer contact |
| line_items[].sku | salesOrder.lines[].itemCode | Priority Sales Order item |
| line_items[].quantity | salesOrder.lines[].quantity | Priority Sales Order quantity |
Martini implementation pattern
Martini receives or retrieves the commerce order, validates the customer and item mappings, checks whether the external order identifier has already been processed, and calls the confirmed Priority REST operation. It captures the generated Priority order identifier, separates business rejection from transient failure, and retries only safe operations.
Martini capabilities used
- workflow orchestration
- API consumption
- data mapping
- business rules
- idempotency checks
- error handling
Pattern 3: Synchronize suppliers and purchase orders
When to use this pattern
Use this pattern when Priority participates in a procurement landscape with NetSuite, SAP S/4HANA, or another purchasing application and supplier, order, and delivery references must remain aligned.
Integration direction
Example Mapping
| Priority Software Field | Canonical Field | Target Field |
|---|---|---|
| Supplier.Code | supplier.externalId | SAP supplier identifier |
| PurchaseOrder.Number | purchaseOrder.sourceNumber | SAP purchasing document reference |
| PurchaseOrder.Lines[].Item | purchaseOrder.lines[].itemCode | SAP material |
| PurchaseOrder.Lines[].DeliveryDate | purchaseOrder.lines[].requestedDate | SAP requested delivery date |
Martini implementation pattern
Martini sequences supplier synchronization before purchase-order processing, translates units and status codes, preserves source references, and applies rules for ownership and approved status transitions. Failed pages or documents are isolated for retry while successful records advance the checkpoint.
Martini capabilities used
- workflow orchestration
- data mapping
- conditional routing
- scheduled synchronization
- validation
- retry handling
Pattern 4: Publish Priority invoices to financial and CRM systems
When to use this pattern
Use this pattern when invoice status, totals, tax information, or payment references from Priority must be available to NetSuite, Microsoft Dynamics 365, Salesforce, or a reporting platform.
Integration direction
Example Mapping
| Priority Software Field | Canonical Field | Target Field |
|---|---|---|
| Invoice.Number | invoice.externalId | Dynamics invoice number |
| Invoice.Customer | invoice.customerId | Dynamics customer reference |
| Invoice.Total | invoice.totalAmount | Dynamics total amount |
| Invoice.Tax | invoice.taxAmount | Dynamics tax amount |
Martini implementation pattern
A Martini workflow polls or receives a confirmed Priority notification, retrieves the complete invoice when needed, normalizes dates, currencies, tax values, and lines, and prevents duplicate posting using the invoice identifier. It captures Priority warnings, approval state, and generated references and supports reconciliation when downstream processing is incomplete.
Martini capabilities used
- API consumption
- scheduled triggers
- data transformation
- business rules
- idempotency
- monitoring and error handling
Applications commonly integrated with Priority Software
Priority ERP can participate in broader commerce, CRM, procurement, finance, and operational landscapes. The pairings below are common enterprise architecture patterns rather than claims of dedicated Priority-specific connectors; exact objects, ownership, and synchronization direction should be confirmed for each implementation.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize Priority Customers, sales activity, order status, and invoice information with customer-facing processes. | Priority Software → Martini → Salesforce | Martini workflows poll or receive supported Priority notifications, map customer and transaction identifiers to Salesforce fields, apply ownership rules, and use retry and reconciliation handling for failed updates. |
| Shopify | Transfer online orders and customer details into Priority while publishing selected product, availability, or fulfillment information back to the storefront. | Shopify → Martini → Priority Software | A Martini workflow validates Shopify customers and items, checks for an existing external order identifier, creates a Priority Sales Order through the REST API, and returns or stores the Priority document reference. |
| Adobe Commerce | Create Priority Sales Orders from commerce transactions and synchronize catalog, inventory, and fulfillment data where the business process requires it. | Adobe Commerce → Martini → Priority Software | Martini consumes commerce payloads, transforms order lines and customer data into the confirmed Priority schema, routes validation failures separately, and schedules reconciliation for status or inventory differences. |
| WooCommerce | Send web orders and customer details to Priority and return selected order or fulfillment status to the storefront. | WooCommerce → Martini → Priority Software | Martini receives or retrieves WooCommerce orders, validates item and customer mappings, creates or updates Priority Sales Orders idempotently, and exposes a controlled status endpoint or scheduled outbound update. |
| NetSuite | Coordinate customer, supplier, item, invoice, and order data when Priority and NetSuite coexist in a multi-ERP or subsidiary architecture. | Priority Software → Martini → NetSuite | Martini acts as an orchestration layer with explicit object ownership, translating Priority identifiers and statuses into NetSuite structures while recording correlation and reconciliation keys. |
| SAP S/4HANA | Exchange master data, procurement, sales, and financial information across a broader enterprise landscape. | Priority Software → Martini → SAP S/4HANA | Martini workflows coordinate API calls in both systems, apply field and code-list transformations, sequence dependent objects, and isolate transient transport failures from business validation errors. |
| Microsoft Dynamics 365 | Synchronize CRM or operational data with Priority ERP information for sales, service, or finance processes. | Priority Software → Martini → Microsoft Dynamics 365 | Martini retrieves changed Priority objects where supported, maps them to Dynamics 365 models, applies business rules for ownership and status, and runs scheduled reconciliation when event delivery is unavailable. |
| Jira | Create or update delivery, implementation, or support work items from selected Priority business events or transaction states. | Priority Software → Martini → Jira | A Martini workflow evaluates Priority statuses, creates or updates Jira issues using correlation keys, and optionally sends selected Jira status changes back through a controlled Priority API process. |
How to build a Priority Software integration in Martini
Objective
Establish the Priority environment connection and confirm the API interface, user permissions, companies, branches, resources, and deployment-specific authentication flow.
Instructions in Martini
- Identify the Priority ERP version, deployment, modules, and API base URL.
- Create a dedicated integration user or API account with least-privilege access.
- Confirm whether the environment uses Basic Authentication, a session, a token, or another flow.
- Store credentials and endpoint settings in Martini protected configuration and secrets.
Objective
Select the trigger that matches the confirmed Priority capabilities and business latency requirements.
Instructions in Martini
- Use a confirmed Priority callback only for selected events that the deployment explicitly supports.
- Use a scheduled workflow when callbacks are unavailable or incomplete.
- Define polling intervals, incremental filters, page sizes, and processing windows with the Priority administrator.
Objective
Read or receive Priority objects while preserving source identifiers, pagination state, and response details.
Instructions in Martini
- Retrieve the confirmed Customers, Suppliers, Items, Sales Orders, Purchase Orders, or Invoices resource.
- Handle pagination and server-side filtering only according to the confirmed Priority API contract.
- Capture HTTP status, Priority business messages, generated identifiers, and correlation data.
Objective
Coordinate dependent operations and isolate transport failures from business validation failures.
Instructions in Martini
- Sequence prerequisite objects such as Customers and Items before Sales Orders.
- Use conditional routing for accepted, rejected, and retryable responses.
- Persist checkpoints and correlation keys so interrupted runs can resume safely.
Objective
Convert Priority-specific payloads into canonical and target-system models without relying on positional or undocumented fields.
Instructions in Martini
- Map identifiers, dates, currencies, tax values, units, statuses, and localized fields explicitly.
- Normalize JSON or XML structures as required by the confirmed Priority interface.
- Apply defaulting and conversion rules only when they are agreed with the business owner.
Objective
Validate data and enforce ownership, duplicate prevention, approval, and transaction sequencing rules before writing to target systems.
Instructions in Martini
- Validate required fields, code lists, permissions, and object relationships.
- Check external order or invoice identifiers before creating new Priority documents.
- Treat an accepted HTTP request separately from completed Priority business processing.
Common Priority Software data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Customers | Customer master data, account details, addresses, and commercial settings. | Salesforce, Shopify, Adobe Commerce, WooCommerce, Microsoft Dynamics 365 | Martini retrieves or receives confirmed Priority representations, normalizes identifiers and addresses, applies ownership rules, and synchronizes changes idempotently. |
| Suppliers | Supplier master data and purchasing relationships. | NetSuite, SAP S/4HANA, procurement applications | Martini validates supplier identifiers and required commercial fields, maps codes and terms, and preserves Priority and external references for reconciliation. |
| Items / Products | Catalog descriptions, units, inventory attributes, and pricing-related data. | Shopify, Adobe Commerce, WooCommerce, Salesforce | Martini transforms item codes, units, prices, and availability into target schemas and uses incremental retrieval when supported by the Priority resource. |
| Sales Orders | Customer orders, order lines, quantities, dates, and fulfillment information. | Shopify, Adobe Commerce, WooCommerce, Salesforce | Martini validates Customers and Items, checks external order identifiers before creation, maps order lines, and stores generated Priority references. |
| Purchase Orders | Procurement transactions, supplier references, order lines, and delivery information. | NetSuite, SAP S/4HANA, procurement applications | Martini maps suppliers, items, quantities, units, and delivery details, applies sequencing and validation, and reconciles status changes. |
| Invoices | Sales or purchasing invoices, tax details, totals, payment references, and invoice lines. | NetSuite, SAP S/4HANA, Salesforce, Microsoft Dynamics 365, data platforms | Martini normalizes invoice lines and financial attributes, captures generated identifiers and business warnings, and prevents duplicate downstream postings. |
Authentication and security considerations
Deployment-specific authentication
Priority API access requires credentials associated with a Priority user or API account. The exact flow may be HTTP Basic Authentication, a session, a token, or another arrangement determined by the deployment and interface.
Least privilege and secrets
- Use a dedicated integration user with only the required company, branch, form, table, and operation permissions.
- Store credentials and environment-specific endpoints in Martini secrets or protected configuration.
- Do not place credentials in mappings, request payloads, or workflow logs.
- Validate authentication and authorization in a non-production environment before enabling writes.
Operational considerations for Priority Software integrations
API behavior and throughput
Confirm pagination, page sizes, filtering, sorting, request limits, session behavior, and any processing windows with the Priority administrator. Public Priority-specific rate-limit values were not verified, so use bounded concurrency and exponential backoff for transient failures.
Data integrity
- Use external identifiers and deterministic duplicate checks for Sales Orders, Purchase Orders, and Invoices.
- Persist checkpoints for scheduled synchronization and reconcile missed or partially processed changes.
- Capture HTTP status, Priority business errors, warnings, generated identifiers, and processing status.
- Validate dates, time zones, currencies, tax codes, units, localized values, required fields, and configured custom fields.
- Test mappings against the customer’s specific Priority version, modules, permissions, and customizations.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration beyond point-to-point calls
Martini provides a workflow layer for coordinating Priority API calls with commerce, CRM, procurement, finance, and operational applications. It can sequence dependent objects, apply validation and business rules, transform payloads, and expose a stable API façade.
Maintainability and operations
- Centralize environment-specific authentication and endpoint configuration.
- Reuse mappings and workflow components across synchronization processes.
- Handle retries, duplicate prevention, reconciliation, and partial failures consistently.
- Use workflow logs and monitoring to trace source identifiers, target identifiers, and failure reasons without exposing credentials.
Frequently asked questions
Priority ERP can be integrated through its REST APIs and API-oriented web services. Enterprise workflows can read and update Customers, Suppliers, Items, Sales Orders, Purchase Orders, and Invoices, while scheduled polling can support synchronization where event notifications are unavailable. Legacy SOAP or other web services and deployment-specific callbacks should be confirmed for the target Priority environment.
Yes. Martini can integrate with Priority Software by consuming confirmed Priority REST APIs, using a validated legacy web-service interface where required, orchestrating scheduled synchronization, mapping data, applying business rules, and exposing controlled APIs for other applications. A native Martini Priority connector was not verified.
No. A dedicated Priority Software connector is not required. Martini can use Priority’s confirmed native integration mechanisms, including REST APIs, deployment-specific authentication, supported callbacks, and validated legacy web services, together with workflows and transformation logic.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Priority Software. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Priority Software, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.
Priority REST APIs are the primary documented mechanism and should generally be evaluated first. SOAP or other web services are legacy options that require version-specific confirmation. Callbacks, bulk behavior, file exchange, and database access should not be assumed without validating the customer’s deployment.
Universal webhook coverage for all Priority business objects and events was not verified. Selected deployments or processes may provide callbacks or event notifications. Martini can receive confirmed callbacks through an exposed API workflow; otherwise scheduled polling and incremental synchronization may be required.
Use stable source identifiers, confirmed modified-date or change-sequence filters where available, and deterministic checks before creating Customers, Sales Orders, Purchase Orders, or Invoices. Persist Priority-generated identifiers and checkpoints, and design retries so a transport failure does not create a duplicate business document.
Yes. Martini can expose a controlled REST API that presents a normalized contract to consuming applications while workflows retrieve or update Priority data behind the façade. This can isolate consumers from Priority-specific schemas, authentication details, customizations, and deployment differences.
Related Martini documentation
API Integration
Security and Operations
Connect Priority Software with Martini
Use Martini to build maintainable Priority ERP integrations around confirmed APIs, deployment-specific callbacks, scheduled synchronization, secure configuration, data mapping, and resilient workflow orchestration.