Priority ERP integration
Priority is one of the most widely used ERPs in Israel, and almost every company running it eventually adds a second system: an online store, a CRM, a warehouse, a customer portal. The question is always the same: how to connect them so the data does not drift apart.
In short
Priority offers three ways to exchange data: the OData REST API for real-time work, the JavaScript Web SDK for working with forms and procedures the way a user does, and form loads (ממשקים) for batch file exchange. The choice is decided not by developer convenience but by limits: in the cloud the API caps calls per minute per user and concurrent requests, and an integration that calls Priority for every small thing hits those caps on its first busy day.
Three paths and when to use each
| Path | Fits | Watch for |
|---|
| REST API (OData) | Orders from the store into Priority, stock and prices back, customer records for the CRM | Each form has to be opened to the API. Cloud limits and the API license |
| Web SDK | Actions that Priority performs through a form or procedure: printing a document, running a procedure, attachments | A JavaScript package whose logic mirrors how a user works in the interface |
| Form loads (ממשקים) | Batch loading: price lists, large reference tables, nightly exchange | Files or XML/JSON, processed on a schedule, with errors visible in the load log |
The developer documentation also covers webhooks, ODBC, and an MCP server. The official portal is prioritysoftware.github.io.
Authentication
- Basic with a Priority user's login and password: the simplest option, and the weakest.
- Personal Access Token in newer versions: Priority recommends it for server-to-server connections.
- OAuth2 through a separate External ID module, on self-hosted installations only. While it is enabled Basic stops working, and that is worth knowing before switching, not after.
An application can also send its own license identifier and key. Without them the request counts against the general API license. Find out from the vendor which licenses you hold before designing anything: it decides how many separate API users you can create.
The limits that decide the architecture
Priority's cloud version applies a fair-use policy. According to the documentation, it limits calls per minute per user, requests in a rolling five-minute window, and concurrent requests with a short queue. It also sets a request timeout and a maximum response size. Exceeding these limits returns HTTP 429. The number of rows in a single response is also capped by a setting.
A common mistake: the store asks Priority for stock every time a product page opens. On a quiet day, it works. On a sale day, the store hits the limit, Priority returns 429, and the buyer sees an error or incorrect stock.
So these are the rules we use to build integrations:
- Data that changes rarely (catalog, prices, customers) is pulled on a schedule or on an event and kept on our side. We do not call Priority for it in real time.
- Only what cannot wait is handled in real time: the order, the payment, the reservation.
- Every call can receive a 429 and retry later with a backoff, not immediately.
- The send queue lives on our side. If Priority is unavailable, the order is not lost; it waits.
- Every operation is idempotent: resending the same order does not create a second document.
Where integrations usually break
- Two masters for the same data. The customer is edited both in the CRM and in Priority, and a month later the records no longer match. Before writing any code, decide which system owns each field.
- Reference data. Unit, warehouse, and payment term codes in the store and in Priority do not match. The mapping table must be explicit and have an owner.
- A load error nobody reads. A document failed to load, the log shows the line, but nobody looks at it. It needs an owner and an alert.
- Priority version upgrades. A form or field changed, and the integration quietly stopped filling it. It needs a test scenario that runs after every upgrade.
What we do
We design the exchange around the limits and licenses, build the queue and the log, connect Priority to a store, a CRM or your own system, and leave a test scenario for upgrades. If an integration already exists and sometimes loses orders, we start with the log: the cause is almost always visible there.
Frequently asked questions
Does Priority ERP have an API?
Yes. A REST API based on the OData standard, plus a JavaScript Web SDK and a form-load mechanism for batch exchange. The documentation is published on Priority's developer portal.
Why is our Priority integration slow or failing under load?
Most often because of the cloud limits: calls per minute per user and concurrent requests are capped, and exceeding those limits returns HTTP 429. The fix is architectural: cache data that rarely changes and keep a queue on your side.
Which authentication should we use?
For server-to-server connections, Priority recommends a Personal Access Token. OAuth2 is available through the External ID module on self-hosted installations only, and while it is enabled, Basic does not work.
Can Priority be connected to an online store?
Yes, it is the most common scenario. Orders and payments go into Priority in real time through a queue, while the catalog, prices, and stock are pulled on a schedule or on an event.
Do we need a separate API license?
Usually yes, and the terms depend on your contract with the vendor. Find that out before designing anything, because the license determines how many API users you can create.
SLAtech LTD