Priority ERP · REST / OData

The Priority API, as it actually behaves

The Priority API is a REST / OData interface, and most of what is written about it describes the specification rather than the behaviour. This page is the other thing: what the API genuinely reaches, what it will not do no matter how the request is phrased, what can still be achieved when the Priority side is built to support it, and the behaviours that cost projects weeks precisely because nothing raises an error. Measured on live systems.

Start here

What the Priority API can and cannot do

Almost every integration that runs late was scoped before this distinction was clear. The API is excellent at one thing and does not do the other at all, and the boundary is not where most teams assume it is.

It can

Reach screens — the ones your licence opens to it. Which screens those are differs per system; see below.
Read records — filtered, sorted, paged and shaped by the query, so the caller asks for what it needs rather than everything.
Create, update and delete records through the screen, so the screen's own validation applies rather than being reimplemented outside it.
Work with subforms — the lines of a document, not only its header.

It cannot

Run a procedure. There is no request that starts one.
Run a report. Output is produced inside Priority, not requested from outside.
Trigger a direct activation, or any of the actions a user launches from a screen.
Reach a screen the licence has not opened — and this failure is silent, which is what makes it expensive.

Read quickly, that right-hand column looks like a wall. In practice it is a design constraint, and most of what sits behind it can still be delivered — by building the Priority side to meet the API rather than asking the API to do something it was never given. That is the next section.

Check this before the estimate

Which screens the API reaches is a per-system answer

Priority carries a per-screen flag that decides whether the API licence may touch that screen at all.

A screen without the flag is not slow over REST, and it does not return a permission error that points at the cause. It is simply not there. Because the flag is set per installation, the answer at one customer is not the answer at the next: an integration that shipped last year can be impossible this year at a different site, with identical code and nothing visible from outside to explain it.

Establishing the real list is a read-only check that takes minutes. Running it before the design rather than after the estimate is the cheapest hour on the project.

There is a second trap inside the first, and it is worse because it looks like an answer. Listing that permission screen without a filter returns one page of results and then stops, with no error and nothing to indicate the list was cut. Read that way, one live system reported six reachable screens. Queried correctly, the same system had ninety-nine. A plan built on the first number would have declared most of the project impossible, and the team would have believed it.

Where the constraint stops being one

What the API will not do directly can still be delivered

The API reaches records on screens. That is the whole contract. But a screen in Priority is not a passive table — it is a place where logic runs, and logic that runs on a screen runs when the API touches that screen too. Build the Priority side deliberately and the boundary moves.

Permissions on the data itself. An external system rarely should see everything a screen can show. The right development inside Priority makes the API return the correct slice per consumer, rather than filtering after the fact in code you also have to trust.
Follow-on actions that would normally need a procedure. Work that a user triggers deliberately can be arranged to happen as a consequence of the record arriving, so the integration writes one record and the rest occurs inside Priority under its own rules.
Producing a file and returning it through the API. Documents and outputs can be generated inside Priority and handed back over REST as base64, which is how an external system receives a finished file without any access to how it was made.
Validation that belongs to the business, not to the interface. Rules enforced on the screen apply to every incoming request, so a second implementation of them never has to exist outside — and never has to be kept in step.

None of this is a workaround in the pejorative sense. It is the difference between an integration designed against Priority and one designed with it, and it is usually the difference between "the API cannot do that" and a working system.

A case in point

Text screens are reachable, and almost nobody knows how

Priority's text screens — the long-form content attached to documents, records and specifications — do not behave like an ordinary field, and a first attempt to write to them over REST tends to conclude that they are out of reach. They are not. There is a specific way to address them, and once you have it the following becomes ordinary work:

Appending to existing content without disturbing what is already there.
Replacing a text screen wholesale, generated from outside and written in as a single operation.
Formatting, not just characters — text that arrives laid out rather than as a wall.
User signatures and other captured content carried in with the text.

Deliberately described rather than demonstrated. The point here is that the capability exists and is worth knowing about before anyone concludes a requirement is impossible — the exact method depends on your version and configuration, and it is the kind of detail that is worth getting right once rather than discovering in production.

Measured, not theorised

Four behaviours that cost time, none of which raise an error

Each of these was found the same way: output that looked entirely reasonable and was wrong. That is what makes them expensive. A crash gets fixed the day it happens.

Paging ends on an empty page, not a short one. There is no continuation link to follow, and a short page is not the end of the data. Code that stops early does not fail — it quietly reports a smaller business than the one you have.
Expanding related records can return fewer of them than exist, and says nothing about it. Fetching parents and each subform separately, then joining them yourself, is more code to write and is the version whose totals reconcile.
Subform records are not addressed the way their parent is. A line inside a document is identified by a combination of columns, and the obvious single-key address returns the wrong row, or none, without complaint.
Some requests are refused before Priority ever sees them, producing an error that describes an entirely different problem. There is a way through, and nothing in the message suggests it.

Described rather than pasted as code, on purpose. What matters is knowing what to watch for; the exact form depends on your version, your licence and how your system was configured, and copying a snippet that was correct for somebody else is how more than one of these was introduced in the first place.

The constraint nobody designs for

Volume is a design input, not something to discover later

API use on Priority is licensed and metered. What is included, and on what terms, is between you and Priority — they set it, they revise it, and it is not our place to describe someone else's commercial terms on our own site. What does belong here is the engineering consequence, which holds whatever the terms happen to be.

An integration that rewrites rows nothing changed in does more work than the business asked for, every single run. One that retries hard on failure can multiply that in an afternoon while appearing, from outside, to be doing nothing at all except failing quietly. Neither shows up as an error, and both are usually discovered from the licence rather than from the logs.

So the design that holds is the dull one: write only what actually changed, make retries deliberate rather than automatic, and know the volume a single run produces before deciding to schedule it every hour. Get that right and the licensing question stops being an argument.

Where this comes from

Priority is an Israeli product, and its deepest experience is here

Priority has been implemented in Israel for decades, across every industry, at a density that exists nowhere else. That is not a claim about who is talented. It is arithmetic. The behaviours above are known here because they were already hit, on real systems, by people who then had to make the project work regardless.

We build REST integrations on Priority for companies in Israel and abroad. Specification first, written in English, with worked examples of failure as well as success, so the team on the other side builds without guessing. If you are scoping an integration and want to know whether your case sits inside the API's contract or needs work on the Priority side to get there, that conversation is short and costs nothing.

And if you would rather your own developers held this knowledge instead of buying it, that is what the API course is for.

Talk to us about an integration