Priority has a genuinely good REST API, and integrations against it still routinely blow their estimates. The reason is never the API - it is that every Priority installation is customised. Here is what to check before you scope, and the patterns that hold up in production.
Key takeaways
- The API is standard; your installation is not. Two Priority sites running the same version can need completely different integration code because of custom forms and fields.
- Get a sandbox environment before you quote. Estimating a Priority integration against production access only, or against no access at all, is guesswork.
- Never write documents in a loop without idempotency. Priority will happily create the same order twice, and reversing a posted document is far harder than preventing it.
- Your Priority partner is part of the project. Field definitions, permissions and sandbox access all come from them, and their response time is often the real critical path.
The Priority ERP API is a REST interface built on OData: every Priority form, such as ORDERS or CUSTOMERS, is an entity under a service root of the form https://<server>/odata/Priority/<ini file>/<company>/. A third-party integration authenticates with a personal access token, and reads, creates and updates documents with ordinary GET, POST and PATCH calls.
Priority is the most common ERP in Israeli mid-market businesses, and integrating with it is one of the most frequent requests I get: connect the website, connect the store, push orders in, pull stock out, get invoices generated automatically.
The good news is that Priority exposes a real, documented REST/OData interface and you are not reverse-engineering anything. The bad news is that estimates for Priority work are wrong more often than for almost any other system, and always for the same reason.
Why Estimates Go Wrong
Priority is sold and deployed through implementation partners, and virtually every installation is customised: extra fields on standard forms, custom forms, company-specific document flows, and validation rules encoded years ago by someone who has left.
So "integrate orders into Priority" is not a known quantity. The order form at one company has the fields you expect. At the next, the field that actually drives pricing is a custom extension with a non-obvious internal name, and there is a mandatory field that nobody remembers adding but which will reject every write until you populate it.
This is why the first question on any Priority project is not technical. It is: can I get a sandbox and a field list?
Pre-Scoping Checklist
Do not quote a Priority integration until you have answers to all of these:
- Is there a test or sandbox environment, and is it a recent copy of production?
- Which API user will the integration use, and what are its permissions? Under-permissioned API users produce confusing errors that look like bugs.
- Which forms are involved, and what are their internal names? These are not always what the UI shows.
- Which fields on those forms are custom, and which are mandatory?
- Who at the Priority partner answers technical questions, and how fast?
- Are there existing integrations already writing to the same documents?
The last one matters. If another system already creates orders, you now have two writers and need to agree numbering and ownership up front.
Priority API Basics: Address, Authentication and Limits
These are the facts from Priority's REST API documentation that shape the code before any customisation comes into it:
| Topic | What the documentation says |
|---|---|
| Service root | /odata/Priority/<ini file>/<company>/, for example .../odata/Priority/tabbtd38.ini/usdemo. The system administrator can send the exact address with the Send Program Activation Link program. |
| Authentication | Personal Access Token (from version 19.1): Basic auth with the token as the username and the literal PAT as the password. Tokens are defined in the REST Interface Access Tokens form. Priority's OIDC migration notes list username-and-password Basic auth as deprecated. |
| Application headers | X-App-Id and X-App-Key identify a licensed application; without them a call uses generic API licensing. |
| Reachable forms | Upper-level forms must be enabled in the Limited Access/API Forms form; their sub-levels follow automatically. |
| Rows per call | Capped by the MAXAPILINES system constant from version 25.1 (default 2,000), by MAXFORMLINES before that. Page with $top and $skip. |
| Rate (Priority Cloud) | 100 calls a minute per tenant, 10 processed at once with up to 15 queued, and requests over 3 minutes are dropped. Throttled calls get HTTP 429. |
| Changes only | $since returns only records changed after a given date and time. |
| Batches | $batch holds up to 100 operations (1,000 before version 21.0) and has no rollback. |
| Errors | JSON since version 19.1; a rejected write carries the form's own message under InterfaceErrors. Form and field names are case sensitive. |
Two consequences people learn late. A loop that writes a few hundred documents can hit the 100-per-minute cap on its own, so throttle on your side instead of waiting for 429s. And because a batch cannot roll back, write each document with its lines nested in one POST (ORDERS with ORDERITEMS_SUBFORM) rather than as a batch of separate calls. Error diagnosis is covered in Priority OData errors.
Patterns That Hold Up
Idempotent writes
Give every outbound document a deterministic external reference - the store order number, the CRM deal ID - and write it into a field on the Priority document. Before creating anything, query for an existing document with that reference. On retry, this turns a duplicate into a no-op.
This is not optional. Network timeouts happen mid-write, and a duplicate posted document in an ERP is an accounting problem, not a data cleanup task.
Stage before you post
Do not translate an incoming payload directly into a Priority write. Land it in your own store first, validate it there, then post. This gives you a retry buffer, an audit trail, and a place to hold records that fail validation without losing them.
Treat lookups as cacheable, documents as not
Item catalogues, price lists and customer masters change slowly - cache them and refresh on a schedule. Documents are transactional and must always be read fresh.
Map errors early
Priority's error responses are informative but terse, and they are the same shape whether the problem is a permission, a missing mandatory field, or a business rule violation. Build a mapping from the errors you hit during development into human-readable messages, and surface those in your error queue. Otherwise every failure looks the same to whoever has to fix it.
The Flows People Actually Build
| Flow | Direction | Notes |
|---|---|---|
| Orders from store or website | In | Most common; needs customer matching first |
| Stock levels out | Out | Scheduled; watch multi-warehouse logic |
| Item catalogue and prices out | Out | Often nightly; price list selection is the tricky part |
| Customer creation and lookup | Both | Match on tax ID, never on name |
| Invoice generation | In | Review with the accountant before automating |
| Document status back to the source | Out | Usually polled; keeps the store in sync |
Can You Build a Chatbot on Top of Priority?
Yes, and the API is what makes it possible. Two different things go by the name of a Priority chatbot. Priority Software sells its own AI assistant for people working inside the ERP: aiERP, launched in 2025, with an AI Companion and agents added in version 26.0. A bot that answers your customers on WhatsApp or on your website is a separate build that reads Priority through the REST API.
A customer-facing bot of this kind does a short list of things well:
- Order status: the customer gives an order number, the bot reads
ORDERSand replies with the status and the shipping document, if one exists. - Stock and price questions, answered from a cache that refreshes on a schedule rather than one API call per question.
- Copies of documents the customer is entitled to, such as an invoice they already received.
The rules that keep it safe: a dedicated API user with read access only to the forms the bot needs; an identity check before any customer-specific data (the phone on the customer card has to match the chat); no document writes without a person approving; and a call budget, since every question that reaches the API counts toward the 100 calls a minute. Connecting a language model such as Claude or ChatGPT to Priority works the same way: the model calls tools you write, and only those tools hold the API credentials. My published range for an AI agent or chatbot is $1,800 - $8,000 over 1 - 3 weeks; the WhatsApp side is covered in AI chatbot for WhatsApp.
Customer Matching Is the Real Work
Almost every Priority integration hits the same wall: the incoming record has an email and a name, and Priority has an accounting-grade customer master keyed on something else. The rules that work:
- Match on a normalised tax or company registration number when you have one. This is the only reliable key.
- Fall back to a stored external ID if a previous integration wrote one.
- If no match, create a new customer - but flag it for review rather than trusting it silently.
- Never overwrite an existing Priority customer record from external data. Add, do not replace.
Name matching produces merged or split customers that surface months later as reconciliation problems. It is not worth the shortcut.
Realistic Timelines
| Scope | With sandbox and responsive partner |
|---|---|
| One-way order push, standard fields | 1 - 2 weeks |
| Orders + stock + customer matching, error queue | 2 - 4 weeks |
| Heavily customised forms, multi-warehouse, invoicing | 5 - 8 weeks |
Without a sandbox, add time and treat every estimate as provisional. Developing against production is possible but slow, because you cannot experiment freely with documents that post to the accounts.
Before You Start
Write down, in one page: which documents you will create, which fields you will populate, what the external reference will be, and what happens on failure. Get your Priority partner to confirm the field names against the actual installation. That page prevents most of the overruns.
To scope a Priority integration for your setup, book a free call. Related: what connects to what in the Israeli software stack, connecting an online store to an ERP, and what an API integration is.
Sources
Frequently asked questions
Does Priority have a REST API?
Yes. Priority exposes a documented REST/OData interface that covers orders, customers, items, stock and the standard document types, with both read and write access. It is a genuine, supported integration surface rather than a workaround. The complexity in real projects comes from the installation being customised, not from the API being limited.
Why do Priority integration quotes vary so much?
Because the work depends almost entirely on how customised your specific installation is, and that is invisible from the outside. Two companies on the same Priority version can need completely different integration code because their order forms have different custom fields, different mandatory validations, and different document flows. A quote given without sandbox access and a field list is a guess, and should be treated as one.
Do I need my Priority partner involved in the integration?
In practice, yes. They control sandbox access, API user permissions, and the definitions of the custom fields you need to write to. Their response time frequently becomes the critical path of the whole project, so it is worth agreeing expectations with them before the build starts rather than discovering a two-week turnaround halfway through.
Can I automatically generate invoices in Priority?
Technically yes, and it is a common requirement. Two cautions apply. First, an invoice is a financial and regulatory document, so the automation should be reviewed with your accountant before it goes live. Second, the write must be strictly idempotent - a duplicate posted invoice is much harder to undo than to prevent. A common safe pattern is to create the document automatically but have a person approve issuance for the first few weeks of operation.
How should I match incoming customers to Priority customer records?
Match on a normalised tax or company registration number wherever one exists - it is the only reliable key. Fall back to a stored external ID if a previous integration wrote one. When no match is found, create a new customer but flag it for human review rather than trusting it silently. Never match on company name, and never overwrite an existing Priority customer record with external data; add information, do not replace it.
What is the base URL of the Priority REST API?
It follows the pattern https://{server}/odata/Priority/{ini file}/{company}/, for example .../odata/Priority/tabbtd38.ini/usdemo in Priority's own documentation. Each form, such as ORDERS or CUSTOMERS, is an entity under that root. The system administrator can send the exact address for your installation with the Send Program Activation Link program.
How do I authenticate to the Priority API with a personal access token?
Use Basic authentication with the token as the username and the literal word PAT as the password. Personal access tokens exist from Priority version 19.1 and are defined in the REST Interface Access Tokens form. Priority lists username-and-password Basic authentication as deprecated, so a new integration should start on a token.
Can I build a chatbot that answers customers from Priority data?
Yes. A customer-facing chatbot reads Priority through the REST API with a read-only API user: order status by order number, stock from a cache, copies of documents. It must check the customer's phone against the customer card before showing anything personal. Priority's own aiERP assistant is a different product, aimed at people working inside the ERP.
Keep reading
Related service
Integrations
Make the systems you already pay for talk to each other.
Have a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.