Priority ERP SDK: A Quick Integration Guide for IT Teams

If your organization runs on Priority and you’ve been handed a “just integrate it” ticket, the first challenge isn’t code — it’s figuring out which of Priority’s integration surfaces you’re actually supposed to use. Here’s the quick version, without digging through the full documentation set yourself — and where a tool like Noca’s Prompt to Flow can take the manual work off your plate entirely.

What is an SDK, exactly?

Before going further, it’s worth pinning down the term itself, because “SDK” gets used loosely. A Software Development Kit (SDK) is a packaged set of tools, code libraries, and documentation that a vendor provides so outside developers can build on top of their system without reverse-engineering it from scratch. In Priority’s case, that’s historically meant a mix of interfaces, code samples, and connection tools for pulling data in and out of the ERP. Today, most of that job has shifted onto Priority’s REST API — so when people say “Priority SDK,” they usually mean “however I’m supposed to connect to Priority,” which in practice is the API described below.

What “Priority SDK” actually means today

Priority has supported integrations for years through older interfaces and SDK-based tooling, but the primary surface for new development today is Priority’s REST API, built on the OData standard. It exposes Priority forms as OData entity collections over standard HTTP, with JSON as the default response format. If you’re starting a new integration, this is almost always where to begin — legacy SDK references are worth knowing about mainly for maintaining older connections. It’s also the exact surface that platforms like Noca connect to when they build a Priority integration for you instead of your team building it by hand.

Getting access before you write a single line of code

Before any request will work, a few administrative steps have to happen first — and most integration delays trace back to skipping one of these:

• Forms must be exposed for API access. Only forms enabled by an administrator through Limited Access/API Forms are reachable — everything else returns an access error, no matter how correct your request is.
• Get the service root URL from your System Administrator. It’s specific to each Priority installation, not a generic endpoint.
• Pick an authentication method up front: Basic Authentication, a Personal Access Token, or OAuth2 via an external identity provider.
• On v18.3 and later, include app-level headers — X-App-Id and X-App-Key — for per-application licensing.
• Know your transaction limits. From v25.1, API users share a monthly transaction pool (a default package covers 2,000 records per 10,000 transactions), so high-volume syncs need to be planned with that ceiling in mind.

This is also the stage where a lot of IT teams’ time actually goes — chasing down administrator access, the right root URL, and the right auth method — rather than writing integration logic. It’s precisely this setup overhead that Prompt to Flow is designed to absorb, handling the connection and authentication details once you describe what you’re trying to sync.

How the API is actually structured

Once access is sorted, the shape of the API is fairly predictable. Endpoints map to Priority forms, exposed as OData collections; sublevels come bundled automatically with their parent forms; and fields and form names are typically uppercase and case-sensitive, which trips up more integrations than it should. Priority also publishes a Postman collection against a demo environment, which is the fastest way to see real request/response shapes before touching a live system.

Common integration pitfalls

A handful of mistakes account for most of the support tickets IT teams end up filing:

• Forgetting to enable a form in Limited Access/API Forms, then assuming the integration itself is broken.
• Hitting cloud rate limits — around 100 calls per minute — and not handling the resulting HTTP 429 responses gracefully.
• Assuming lowercase field names will work, when the API expects uppercase, case-sensitive form and field names.
• Underestimating the shared transaction pool introduced in v25.1, especially for high-frequency syncs across multiple integrations.
• Building against sandbox credentials and only discovering production differences after go-live.

Noca’s platform is built to sidestep most of this list by design — connections, retries, and field mapping are handled once you describe the outcome you need, rather than left for each developer to rediscover the same pitfalls independently.

Where Prompt to Flow fits in

Once the access and structure questions are answered, the actual work — building the logic that keeps Priority in sync with your CRM, e-commerce platform, or finance tools — is usually the bigger time sink. Prompt to Flow is built for exactly that part: instead of hand-coding each request, handling retries, and mapping fields form by form, you describe the workflow you need, and the integration, including authentication and field mapping, gets built behind the scenes. For IT teams managing several ERP-connected systems at once, that’s the difference between one more integration to maintain and one more workflow that maintains itself.

Where this leaves you

Most of the friction in a Priority integration isn’t the API itself — it’s the setup steps that happen before the first successful call. Get the access, authentication, and form exposure right, and the rest is largely predictable. If you’d rather skip the manual build entirely, see how Prompt to Flow handles it, or check the pricing page to see what fits your team.

FAQ

Does Priority ERP have a proper REST API?

Yes. It’s OData-based, exposes forms as entity collections, and supports Basic Authentication, Personal Access Tokens, and OAuth2.

Is OAuth2 required to connect to Priority?

No — it’s one of three supported methods, alongside Basic Authentication and Personal Access Tokens. Which one fits depends on your security requirements and whether an external identity provider is already in place.

What’s the fastest way to prototype a Priority integration?

Start with Priority’s Postman collection against its demo environment to see real request and response shapes before building anything against a live system.