The API Report CardAPI Index
THE API REPORT CARD / Manufacturing / QAD
QAD

QAD API

qad.com

REST business-document APIs (JSON) cover sales orders, purchases, items, inventory, and work orders via the QAD Integration Platform. Docs are in-product Swagger at per-instance URLs, so only credentialed customers can read them; there is no public portal or sandbox.

Last verified: July 2026Manufacturing
API GRADE
F
VERIFIED JUL 2026

SCORECARD

ExistenceGOODREST business-document APIs (JSON) exist for core ERP entities, orchestrated through the QAD Integration Platform.
AccessFAILDocs and test calls live inside each customer's instance; non-customers cannot even read the API reference.
CoveragePOORMany transactional flows still depend on Progress .p programs and QXtend XML; no first-party webhooks or event stream.
AuthFAIL
Docs & DXFAILSwagger UI is in-product at per-instance URLs; no public portal, sandbox signup, or rate-limit documentation.
StabilityMIXEDLegacy field limits (8-char usernames, 24-char part descriptions) leak into payloads; rate caps surface only empirically.
MORE FROM THE REPORT CARD
Epicor KineticFAccolent ERPDAptean FoodFAspenTechF
Supergood: QAD has an API, but using it means gates, contracts, or workarounds. Ours doesn't: stable endpoints, normalized JSON, managed auth.

Frequently asked questions

QAD scores F on the API Report Card. REST business-document APIs (JSON) cover sales orders, purchases, items, inventory, and work orders via the QAD Integration Platform. Docs are in-product Swagger at per-instance URLs, so only credentialed customers can read them; there is no public portal or sandbox.

Tried to integrate with QAD?
SOURCES
No open self-serve developer portal, REST/Swagger docs are delivered in-product per customer instance, so ISVs and integrators cannot evaluate the API surface, build prototypes, or read reference docs without an existing QAD customer relationship qad.com ↗
Rate limits, throughput SLAs, and concurrency caps on the REST surface are not publicly documented, forcing integrators to discover limits empirically and engineer retries qad.com ↗
Hybrid Progress OpenEdge / REST architecture means many transactional flows still depend on Progress .p batch programs and traditional QXtend/XML transport; integrators frequently bridge between Progress-era interfaces and the newer REST endpoints progress.com ↗
Cloud Service Delivery's reported ~25-day SDLC cycle to deploy customer-requested changes (including integration changes) blocks rapid iteration on API/integration work g2.com ↗
Legacy field-size constraints (8-char usernames, 24-char part descriptions) propagate into API payloads, integrators must accommodate truncation when reconciling QAD with modern downstream systems softwareadvice.com ↗
No first-party webhook or event-stream surface broadly documented for QAD business documents, real-time integrations rely on QAD Integration Platform publish/subscribe, polling REST, or custom Progress triggers, which is brittle at scale makini.io ↗
A paid third-party connector and consulting ecosystem (Broom Street QAD APIs, Makini, JASCI, Affinda, eNoah, Strategic Information Group, Logan Consulting) exists primarily to abstract the QAD API surface and operate it in production, adding per-connector subscription/services cost and a second vendor between the customer and their data broomstreet.com ↗
API behavior and module-specific integration patterns vary across QAD modules (Adaptive ERP core vs. EQMS vs. DSCP vs. GTTE), EQMS has its own dedicated Integration Technical Reference and integration patterns separate from the core ERP REST surface qad.com ↗
For on-prem QAD EE and MFG/PRO customers (still a meaningful share of the install base), exposing REST/Integration Platform endpoints to outside SaaS integrations requires VPN/firewall/network changes that customer IT must own, slowing or blocking third-party integrations support.leading2lean.com ↗
Heavy regulated-industry footprint (GxP life sciences, IATF automotive) means API/integration changes often require re-validation under FDA 21 CFR Part 11 or IATF 16949, increasing the operational cost of every integration change and slowing customer adoption of new endpoints qad.com ↗
Service Delivery is widely criticized as 'worst in class' with consultants described as lacking product knowledge; Cloud Service Delivery reportedly takes ~25 days just to deploy an SDLC change request g2.com ↗
Steep learning curve and non-intuitive UX, users routinely have to navigate multiple screens to find data and must memorize menu paths that don't reflect the actual function capterra.com ↗
Legacy MFG/PRO field-size limits leak into the modern product, 8-character usernames and 24-character part descriptions are commonly cited because the underlying program logic dates to the early 1980s softwareadvice.com ↗
System is described as inflexible and expensive to customize relative to modern cloud-native ERPs; reporting and workflow customization is painful trustradius.com ↗
Menu structure is 'insanely large' with many obscure or duplicate paths, making onboarding and self-service navigation difficult softwareadvice.com ↗
Pricing is opaque and quoted on a per-module/per-user basis (commonly $150–$250/user/month), with implementation costs often equal to or larger than year-one license erp-pilot.com ↗
Heavy reliance on Progress OpenEdge ABL (4GL) for back-end batch logic, most .p programs persist on the server, modernization is being done module-by-module rather than via a full rewrite, leaving a hybrid stack visible to customers and integrators progress.com ↗
Reports of inconsistent support responsiveness and disregard for customer priority schedules in Cloud Service Delivery g2.com ↗
Upgrades between major versions can be disruptive for heavily customized on-prem MFG/PRO and QAD EE customers, requiring re-validation cycles (especially for GxP-regulated life sciences) gartner.com ↗
© Supergood Systems, Inc.