Priority Software ERP — Integration Research Report

Date: 2026-03-29 Target: Priority Software ERP Purpose: Assess API capabilities for Orcha integration (document ingestion, reference data sync, approval workflows)

1. Summary — Capability Matrix

Overall assessment: Strong integration potential. Priority exposes all user-facing forms as OData entities with full CRUD. After deep research across SDK docs, SOP documents, and community GitHub repos, all key financial form names are now confirmed: SUPPLIERS, ACCOUNTS, COSTCENTERS, PINVOICES (A/P invoices), PORDERS (purchase orders), FNCTRANS (journal entries). Priority has 3,000+ internal forms; the customer must enable specific forms for API access via the FORMLIMITED configuration screen.

2. API Landscape

2.1 Core API — OData REST

• Protocol: OData (Open Data Protocol) over REST/HTTP
• Base URL format: https://{instance}.priority-connect.online/odata/Priority/{env}.ini/{company}
• Demo/sandbox: https://t.eu.priority-connect.online/odata/Priority/tabbtd38.ini/usdemo (available since v25.0)
• Response format: JSON (default)
• Max response size: 350MB, 2,000 records per request (configurable via MAXAPILINES in v25.1+)
• Developer portal: prioritysoftware.github.io/restapi
• Postman collection: Available via developer portal for demo environment

2.2 Authentication

2.3 Rate Limits & Throttling

• 100 API calls per minute per user
• 15 requests queued (10 concurrent + 5 in queue)
• 3-minute timeout per request
• Transaction counting: Write operations (POST/PATCH creating or updating forms) consume transactions, purchased in packages of 10,000/month. Forms classified as premium, regular, or free.

2.4 Licensing & Access Requirements (What the Customer Needs)

The API is NOT automatically available to all Priority customers. There are several prerequisites:

What must be purchased/enabled:

Transaction cost model:

Example: Creating an order with 5 line items = 6 transactions (1 parent + 5 children). Each form's transaction type is viewable in the "View License Details" report.

Customer setup steps (admin must do this):

1. Renew licenses — System Management > System Maintenance > Renew License
2. Create API user — Create a dedicated user (e.g., "orcha"), mark as "Active user" in Permissions
3. Set API license — On the user's Licenses tab, select "App-Only License"
4. Set API-user field — On the employee card, set the API-user field
5. Generate auth token — System Management > Authentication Tokens for REST Interfaces
6. Enable forms for API — Open FORMLIMITED ("Limited Access/API Forms"), retrieve each form needed, and mark "Available for API"
7. Send activation link — System Management > Users > Send Program Activation Link, select "API" as activation type

What this means for Orcha:

• The customer cannot just give us an API key — they need to go through the setup above
• We should provide a setup checklist listing exactly which forms to enable in FORMLIMITED (PINVOICES, SUPPLIERS, ACCOUNTS, COSTCENTERS, etc.)
• Transaction package costs are an ongoing expense for the customer — we should design for efficiency (batch operations, delta sync, avoid unnecessary writes)
• Pricing for API module + transaction packages is not publicly listed — the customer needs to contact Priority sales or their Priority partner

2.5 Additional API Layers

3. Write Capability Verification

Confidence: HIGH — Write operations are fully documented and confirmed.

3.1 Documented Write Operations

3.2 Confirmed Entity/Form Names

The following form names were verified across Priority's official SDK documentation, OData API PDF, REST API developer portal, SOP documents, and community GitHub repositories. Priority has over 3,000 internal forms (per ODBC docs); these are the ones relevant to Orcha's integration needs.

Sales & A/R (Accounts Receivable)

Purchasing & A/P (Accounts Payable)

Master Data

Financial / General Ledger

Payments & Banking

Tax / VAT

Reconciliation

Documents / Shipping

Universal Sub-forms

System / Configuration

Note: The $metadata endpoint on the sandbox returned 401 (authentication required). The form names above are confirmed from documentation and production code, but a customer's specific Priority instance may have additional custom forms (prefixed with a 4-letter customer code, e.g., XXXX_CUSTOMERS).

3.3 Key Technical Details

• Composite keys: Some financial forms (e.g., AINVOICES) use composite keys: AINVOICES(IVNUM='T9696',IVTYPE='A',DEBIT='D')
• File attachments: Base64-encoded in format data:application/pdf;base64,{content} with SUFFIX field
• Text fields: Support HTML, append mode, and digital signatures
• Form access control: Forms must be explicitly enabled for API access via the "Limited Access/API Forms" configuration (admin step required on customer side)

4. iPaaS & Middleware Findings

4.1 Workato (Highest Signal)

Connector type: Community connector (published Feb 2025) 14 operations confirmed:

Verdict: Full CRUD + file upload + batch. This is a thin wrapper around the OData API — confirms direct API has the same capabilities.

4.2 Make.com

• Listed on Priority Software Marketplace
• Supports automation workflows with 2,400+ apps
• No-code environment for creating, updating, deleting entities
• Processes through official Priority API endpoints

4.3 Zapier

• Available on Priority Software Marketplace
• Described as "Automate any sync tasks with Zapier iPaaS"
• Details on specific operations not publicly documented

4.4 Other Connectors

5. Alternative Channels

5.1 Webhooks (Outbound)

Status: Available — Priority fires webhooks via BPM (Business Process Management) rules.

Example payload:

{
  "DOCUMENTS_P": {
    "PDOCNO": "SH2000000880",
    "CDES": "David Smith",
    "CURDATE": "2020-07-28T00:00:00"
  }
}

Use for Orcha: Receive real-time notifications when invoice status changes (approved, paid, rejected) without polling.

5.2 File-Based Integration (FTP/SFTP)

• XML file exchange documented in financial module integrations
• Export directory pattern: invoice_out on FTP server
• Import directory pattern: invoice_paid on FTP server
• Used for payment status confirmations (PAID/REJECTED with voucher numbers)
• Pricing likely custom-quoted, not self-service

5.3 ODBC

• Direct database access available for on-premise installations
• Not applicable for cloud/SaaS deployments

6. Orcha-Specific Deep Dive

6.1 Write Reference Data (Cost Centers, Accounts, GL Codes)

Form name confirmation: Unlike the initial report, these form names are now confirmed across multiple independent sources (Priority SDK Form-Columns page, SDK PDF Removed-Entities section, and production GitHub repos). COSTCENTERS appears as a reference table in the SDK Form-Columns documentation. ACCOUNTS is referenced both as a menu entity in the SDK and as a data table in community code (field ACCNAME used for lookups).

Customer setup required: The Priority admin must enable each form in FORMLIMITED ("Limited Access/API Forms") before API access works.

6.2 Write Transactional Data (Invoices, Credit Notes)

Confirmed JSON for invoice line item creation:

POST serviceRoot/AINVOICES(IVNUM='T9696',IVTYPE='A',DEBIT='D')/AINVOICEITEMS_SUBFORM
{
    "PARTNAME": "TR0001",
    "TQUANT": 3
}

6.3 Attach Documents (PDF Upload)

Confirmed JSON for file attachment:

POST serviceRoot/ORDERS('SO21000113')/EXTFILES_SUBFORM
{
    "EXTFILEDES": "Invoice scan",
    "EXTFILENAME": "data:application/pdf;base64,{base64content}",
    "SUFFIX": ".pdf"
}

Note: Workato connector also exposes "Upload file" as a dedicated operation, confirming this works reliably.

6.4 Trigger/Manage Approvals

What we know: Priority's BPM engine handles approval workflows. Engini's connector mentions "activate form activations" — suggesting API can trigger procedures/activations on forms. This is the mechanism for approval actions but needs vendor confirmation for specific approval forms.

6.5 Read Status / Lifecycle Changes

Recommended approach: Use webhooks for real-time status notifications (approved, paid, rejected) instead of polling. Configure BPM rules on the relevant financial forms.

6.6 Sync Reference Data Inbound (Read from Priority)

All reference data reads are straightforward GET operations. Form names and key fields confirmed across SDK documentation and production GitHub repos.

Orcha Integration Capability Summary

7. Recommended Path Forward

Architecture Decision

Recommended: Direct OData API integration. The Priority OData API provides full CRUD on all forms, file attachments, batch operations, and webhook-based event notifications. This gives Orcha complete control without middleware costs.

Phased Integration Plan

Phase 1 — Discovery & Reference Data Sync (Week 1-2)

1. Obtain customer's $metadata endpoint to get complete entity list and field definitions
2. Verify form names for: accounts, suppliers, cost centers, A/P invoices
3. Implement OAuth2 or PAT authentication flow
4. Build reference data sync: Pull chart of accounts, suppliers, cost centers from Priority into Orcha for validation

Phase 2 — Document Push (Week 3-4)

1. Implement invoice creation via POST to A/P invoice form (likely CINVOICES)
2. Implement line item creation via POST to invoice items sub-form
3. Implement PDF attachment via POST to EXTFILES_SUBFORM with base64-encoded PDF
4. Implement batch operations for bulk invoice push (up to 100 per batch)

Phase 3 — Approval & Lifecycle (Week 5-6)

1. Configure webhooks in customer's Priority instance for invoice status changes
2. Build webhook receiver in Orcha to process status notifications (approved, paid, rejected)
3. Investigate approval triggers — work with Priority support to confirm how to trigger approvals via API activations
4. Implement status polling as fallback for forms without webhook configuration

Phase 4 — Production Hardening (Week 7-8)

1. Rate limiting compliance — ensure <100 calls/minute, implement queuing
2. Transaction monitoring — track API transaction consumption
3. Error handling — handle 409 (conflict), timeout, and batch partial failures
4. Retry logic with exponential backoff for transient failures

Key Risks & Mitigations

8. Sources

Official Documentation

• Priority Developer Portal — REST API
• Priority Developer Portal — Home
• Priority Developer Portal — Webhooks
• Priority OData API PDF
• Priority SDK Documentation
• Priority OData — OData.org
• Priority API Installation Guide
• Priority OData API Support

iPaaS & Middleware

• Workato — Priority Software Integration
• Make.com — Priority Integration
• Priority Marketplace — Make Connector
• Priority Marketplace — Zapier
• APPSeCONNECT — Priority Integration
• Engini — Priority ERP
• iConduct — Priority API Connector

Community & Third-Party

• Noca — Priority API Guide
• Noca — Priority Integration Guide
• GitHub — MordiSacks/priority-api (PHP client)
• GitHub — victor-rioba/priority-sdk (TypeScript SDK)
• GitHub — talc87/priority_data_pipeline (Python)
• GitHub — PrioritySoftware (Official)
• Ex Libris — Priority Financial Module Integration
• API Tracker — Priority Software

Vendor Website

• Priority Software — ERP
• Priority Software — ERP Integration
• Priority Software — Financial Services
• Priority Software Marketplace