canonical: https://jentic.com/apis/priority-software.github.io/priority-software

# Priority Software REST API

Priority Software REST API provides OData-based access to Priority ERP forms and entities. The API supports full CRUD operations with OData query parameters including filtering, sorting, pagination, field selection, and entity expansion. It covers metadata retrieval, entity management through dynamic paths, and navigation to related subform entities. Rate limits are set at 100 calls per minute per user on cloud deployments.

## For AI agents

Access Priority ERP data through OData protocol. Query, create, update, and delete business entities across all Priority forms with filtering, sorting, and pagination support.

## Scope

Does not handle payroll processing, HR management, or CRM-specific features - use for OData CRUD access to Priority ERP financial and operational forms only.

## Capabilities

- Query Priority ERP entities with OData filter, select, expand, and orderby parameters
- Create new business records in any Priority form through the generic entity endpoint
- Navigate parent-child entity relationships through OData navigation properties
- Retrieve full OData schema metadata describing all entity types and relationships
- Paginate large result sets using top, skip, and server-side next-link cursors
- Delete entities by key from any Priority form collection
- Fetch Priority system version and server environment information

## Use cases

### ERP Data Querying and Reporting

Query Priority ERP forms using OData conventions to extract business data for reporting. The API supports filtering with expressions like CUSTNAME eq 'John', sorting with $orderby, field selection with $select, and pagination with $top and $skip. MAXAPILINES defaults to 2000 records per page in Priority v25.1+. This enables building custom dashboards and reports without direct database access.

Example prompt: List entities from the ORDERS form with $filter set to 'CURDATE gt 2026-01-01' and $top set to 50, then retrieve the first order's ORDERITEMS subform

### Business Record Management

Create, update, and delete business entities across all Priority ERP forms through a unified REST interface. The API uses dynamic entity paths where the form name becomes the URL segment. POST creates new records, PATCH updates existing ones by key, and DELETE removes records. This enables automated data entry from external systems into Priority without manual ERP interaction.

Example prompt: Create a new entity in the CUSTOMERS form with CUSTNAME 'Acme Corp' and PHONE '555-0100', then verify it exists by querying with a filter on CUSTNAME

### Entity Relationship Navigation

Navigate hierarchical relationships between Priority forms using OData navigation properties. Access subform data such as order line items, invoice details, or customer contacts by traversing the parent entity key and navigation path. This allows agents to reconstruct complete business documents from their component parts without multiple unrelated queries.

Example prompt: Retrieve order 'ORD001' from the ORDERS entity set, then navigate to its ORDERITEMS subform and return all line items with their quantities and prices

### AI Agent ERP Integration via Jentic

AI agents can access Priority ERP data through Jentic without configuring OData URLs or managing Basic Auth credentials. Jentic provides operation schemas for each Priority endpoint and handles authentication, so agents can query business data, create records, and navigate entity relationships by describing their intent in natural language.

Example prompt: Search Jentic for 'query priority erp orders', load the listEntities operation schema, and execute it with entitySet 'ORDERS' and $top 10

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/` | List available entity sets in the Priority instance |
| GET | `/$metadata` | Get full OData schema metadata |
| GET | `/{entitySet}` | Query entities with OData filter and sort |
| POST | `/{entitySet}` | Create a new entity in a Priority form |
| GET | `/{entitySet}('{key}')` | Retrieve a single entity by key |
| PATCH | `/{entitySet}('{key}')` | Update an entity with partial data |
| DELETE | `/{entitySet}('{key}')` | Delete an entity by key |
| GET | `/{entitySet}('{key}')/{navigationProperty}` | Navigate to related subform entities |

## Key resources

- **Metadata** — Service root, OData schema metadata, entity-specific metadata, and version information
- **Data** — CRUD operations on Priority entities with OData query parameters and navigation properties

## AI readiness

This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use.

- **Score:** 61 / 100
- **Maturity:** AI-Aware
- **Dimensions:**
  - Foundational Compliance: 81 / 100
  - Developer Experience & Jentic Compatibility: 59 / 100
  - AI-Readiness & Agent Experience: 54 / 100
  - Agent Usability: 94 / 100
  - Security: 37 / 100
  - AI Discoverability: 70 / 100
- **View full report:** https://jentic.com/apis/priority-software.github.io/priority-software/scorecard
- **How the score is calculated:** https://docs.jentic.com/reference/api-readiness-framework/overview/
- **More about the dimensions:** https://docs.jentic.com/reference/api-readiness-framework/specification/#dimensional-model-overview

### Score it yourself

Every API in the directory is allowlisted, so you can re-score it with no key required.

- **Score your own API:** https://jentic.com/scorecard.md
- **Scoring CLI agent skill:** https://github.com/jentic/jentic-api-scorecard/blob/main/skills/jentic-api-scorecard/SKILL.md

```sh
npx @jentic/api-scorecard-cli score <openapi-url>
```

## Why Jentic

- **Setup:** Wiring the Priority Software REST API by hand means choosing Basic auth or a Personal Access Token, assembling the templated OData host with your server, environment, and company, and handling the {entitySet} path yourself. Through Jentic you install once, import the Priority Software REST API from the API Directory, store the credentials once, and your agent calls it.
- **Permission scoping:** Priority puts the entity key in the URL path (/{entitySet}('{key}')), so a rule can pin your agent to specific entity records. You choose the operations it may call, so a destructive one like DELETE on an entity is not included unless you add it.
- **Credential handling:** Your Priority Basic auth credentials or Personal Access Token are stored once, encrypted, by your own Jentic One instance and injected at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'query Priority ERP orders' or 'create a customer in Priority', and Jentic returns the matching OData operation with its input schema, including the dynamic entitySet path variable, so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Priority REST API** — Same ERP system accessed through a different vendor domain with batch operations and metadata cache clearing
- **Priority REST API** — Another vendor-official spec for the same Priority ERP with OAuth2 support and batch operations
- **Shopify API** — E-commerce platform to sync orders and inventory with Priority ERP

## FAQ

### What authentication does the Priority Software REST API use?

The API supports Basic authentication with Priority username and password, Personal Access Tokens (PAT) via the Authorization header, and application license keys via X-App-Id and X-App-Key headers. Through Jentic, these credentials are stored encrypted in the vault and agents authenticate without seeing raw passwords or tokens.

### What are the rate limits for the Priority Software REST API?

Cloud deployments enforce 100 API calls per minute per user. The API returns a 429 status code when this limit is exceeded. On-premise installations may have different limits depending on server configuration. The MAXAPILINES constant (2000 records in v25.1+) limits the number of entities returned per page.

### Can I query Priority ERP data with filters and sorting?

Yes. The GET /{entitySet} endpoint supports standard OData query parameters: $filter for conditional filtering, $orderby for sorting, $top and $skip for pagination, $select for field projection, and $expand for including related entities inline. Filter syntax uses OData conventions like 'CUSTNAME eq John' or 'CURDATE gt 2026-01-01'.

### How do I access subform data in Priority through the API?

Use the navigation property path pattern: GET /{entitySet}('{key}')/{navigationProperty}. For example, to get order lines for order 'ORD001', request GET /ORDERS('ORD001')/ORDERITEMS. The response returns the child entities with all their fields. You can apply $filter, $select, $top, and $skip to the subform results.

### How do I get metadata for a specific Priority form through Jentic?

Search Jentic for 'get priority entity metadata', load the getEntityMetadata operation schema, and execute it with the entityName parameter set to the form name (e.g., 'ORDERS'). This returns the full field definitions, data types, and relationships for that form. Available in Priority v25.0 and later. Install with pip install jentic.

### What OData version does the Priority REST API use?

The Priority REST API uses OData v4 conventions. You can verify the exact version by calling GET /GetPriorityVersion() which returns the Priority version and server information. The full schema is available via GET /$metadata in XML format describing all entity types and their relationships.

### Can I limit what my agent is allowed to do with the Priority Software REST API?

Yes. Because you run Jentic One yourself, your own rules decide which Priority operations the agent may call, so you can grant read-only access with GET on /{entitySet} and the metadata endpoints while withholding POST creates, PATCH updates, and DELETE on entities. Since Priority puts the entity key in the URL path, such as /{entitySet}('{key}'), a rule can also pin the agent to specific records or forms rather than the whole ERP. The stored Basic auth credentials or Personal Access Token are injected only at execution time, so the agent never sees them and can only reach the endpoints you have allowed.
