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.

Priority ERP API Integration: A Developer's Field Guide

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.

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.

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

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-3 weeks
Orders + stock + customer matching, error queue	4-7 weeks
Heavily customised forms, multi-warehouse, invoicing	8-14 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.