Your ERP is only as valuable as the data you can get out of it. Here’s how Acumatica’s open integration layer puts business intelligence, automation, and connectivity firmly in your hands.
Every business leader has experienced the frustration of data trapped in silos. You invested in an ERP to become the system of record for your organization but if your team is still exporting CSVs to refresh a Power BI dashboard or asking IT to write custom code every time you need to connect a new app, the promise of a connected enterprise remains out of reach.
Acumatica was architected from the ground up with openness in mind. Its REST API and OData feeds aren’t afterthoughts bolted onto a legacy platform they’re first-class citizens in the product. Understanding how they work, when to use each approach, and what each means for your organization is one of the most valuable conversations you can have before your next integration project.
Why this Matter to You
The ability to connect, extract, and push data without vendor lock-in or expensive middleware is a direct business capability it reduces integration costs, accelerates reporting, and gives your organization the agility to adopt new tools without re-platforming your ERP.
Two Paths Out of Your ERP: REST API vs. OData
At a high level, Acumatica offers two families of integration technology. Think of them as serving different jobs-to-be-done:
REST API
A transactional, action-oriented channel for creating, reading, updating, and deleting ERP records programmatically. Best for system-to-system integrations and business process automation.
OData Feed
A query-oriented, read-focused data channel that speaks the language of Excel, Power BI, and other BI tools. Best for analytics, dashboards, and self-service reporting.
Neither approach is universally “better.” The right choice depends on what you’re trying to accomplish and in many mature integrations, you’ll use both. Let’s go deeper on each
The REST API: Your ERP as a Business Service
Acumatica’s REST API exposes business logic not just raw database tables. When a developer calls the API to create a sales order, Acumatica doesn’t just write a row to a table; it runs the same validation rules, defaulting logic, and workflow triggers that the application UI would. This is an important distinction from direct database access or legacy flat-file integrations.
The API follows the widely adopted OData v4 standard at its protocol layer, which means it uses predictable, standards-based URL patterns and JSON payloads that any modern development platform can work with no proprietary SDKs required.
"When you integrate via the REST API, you’re not bypassing Acumatica you’re invoking it. Business rules stay enforced.”
What the REST API enables
- Bidirectional sync — Push data into Acumatica (new customers, purchase orders, time entries) from external systems in real time.
- Process automation — Trigger Acumatica actions release invoices, approve POs, advance workflows from external platforms or RPA tools.
- eCommerce & portals — Sync orders, inventory, and customer data between Shopify, Magento, or a custom portal and your ERP.
- Custom applications — Build internal tools or mobile apps that read and write ERP data without embedding business logic outside Acumatica.
Key capabilities for IT leaders
The REST API supports endpoint versioning, meaning integrations don’t break when Acumatica upgrades. It also exposes custom fields and custom DACs (Data Access Classes) created during your implementation, so bespoke data structures are just as reachable as standard fields. Authentication uses OAuth 2.0, aligning with modern security standards.
OData: BI-Ready Data Without Writing Code
OData (Open Data Protocol) is an OASIS-standardized protocol for querying and consuming data over HTTP. Think of it as a “live database connection” that BI tools like Power BI, Excel, Tableau, and others natively understand. Instead of scheduling a CSV export at midnight, your dashboards refresh against a live OData feed whenever you open them. Acumatica provides two distinct flavors of OData and this is where many implementations miss an opportunity or make a wrong turn. They serve different audiences and have meaningfully different trade-offs.
GI-Based OData vs. DAC-Based OData
This is the nuance that separates well-architected Acumatica reporting environments from frustrating ones. Here’s how to think about the difference.
Dimension | GI-Based OData (Generic Inquiry feeds) | DAC-Based OData (Contract-Based API feeds) |
Who configures it | Business analyst / power user via the GI screen | Developer or advanced configurator via the Contract-Based API screens |
Primary audience | Business / Finance teams | IT / Developers |
Data shape | Denormalized, joined, pre-filtered views purpose-built for reporting | Normalized data objects closely mirroring the Acumatica data model |
Business logic applied? | Yes GI queries respect field security and company context | Partial exposes raw DAC data; some logic requires additional filtering |
Custom fields visible? | Yes user-defined fields and custom attributes can be added to GIs | Yes if the DAC endpoint is extended to expose them |
Ease of setup | Low/medium — configurable in the UI without coding | Medium/high requires API schema knowledge |
Query flexibility in BI tool | Moderate — pre-shaped by the GI definition; limited server-side filtering | High full OData query syntax ($filter, $select, $expand) available |
Performance (large datasets) | Can be limited; GI queries can be heavy if not optimized | Generally, more efficient; DAC-level access is leaner |
Ideal use case | Finance dashboards, operational reports, self-service analytics | Data warehouse feeds, complex BI models, developer-built integrations |
Acumatica upgrade risk | Low GI definitions are configuration, not code | Moderate tied to DAC schema; upgrades may require endpoint review |
GI-Based OData in practice
A Generic Inquiry in Acumatica is a configurable, SQL-like query built in the application UI no code required. Once configured, any GI can be published as an OData feed with a few clicks. Your CFO’s team can then connect Power BI directly to that feed and get a live AR Aging dashboard, or your controller can pull open PO data into Excel for weekly reviews refreshing with a single click rather than waiting for an IT export.
Scenario: Finance team empowerment
The controller wants a live dashboard showing open invoices by customer segment and sales rep. An analyst builds a GI that joins the AR, Customer, and Salesperson tables, filters to open status, and publishes it as an OData feed. Power BI connects directly. No developer involvement after initial setup. The dashboard refreshes hourly.
DAC-Based OData in practice
Data Access Classes are the underlying object model of Acumatica the structures that define every record type. The Contract-Based REST API exposes these objects as OData endpoints with full query syntax support. This is more powerful for technical scenarios: feeding a data warehouse nightly, building a complex Power BI data model that needs to join objects in ways a GI can’t express, or providing raw normalized data to a developer who will transform it downstream.
Scenario: Data warehouse integration
The IT team is building a Snowflake data warehouse that consolidates ERP, CRM, and HCM data. They use DAC-based OData endpoints to pull normalized AR Invoice, SO Order, IN Item, and GL Transaction records on a scheduled basis. The transformation and joining logic live in the warehouse layer, giving analysts full flexibility.
Choosing Your Approach: A Decision Framework
Rather than a one-size-fits-all answer, think of each approach as the right tool for a specific job:
Use REST API when… | You need to write data back to Acumatica, trigger business processes, or build real-time, transactional integrations with other systems. |
Use GI-Based OData when… | Business or finance users need self-service analytics, live dashboards, or Excel/Power BI refreshes without IT involvement for ongoing maintenance. |
Use DAC-Based OData when… | Developers need raw, normalized object data for data warehouses, complex BI models, or integrations requiring full OData query expressiveness. |
Use all three when… | Your integration architecture matures: REST for transactional sync, GI-OData for operational dashboards, and DAC-OData for the analytical data layer. |
The Business Case: Why Open Integration Matters
These aren’t just technical features they translate directly to business outcomes that matter to executives:
For the CEO / President: Open APIs mean you’re not locked into Acumatica’s ecosystem for every adjacent capability. Best-of-breed sales tools, manufacturing execution systems, or workforce management platforms can integrate cleanly. Your ERP investment compounds as your software stack evolves.
For the CFO / Controller: Live OData feeds eliminate the “stale data” problem in financial reporting. Month-end processes accelerate when dashboards refresh continuously rather than waiting for batch exports. And self-service analytics reduce the burden on IT for routine reporting requests your team gets answers faster, at lower cost.
For the CIO / IT Director: Standards-based protocols (REST, OData v4, OAuth 2.0, JSON) mean your integration team uses the skills they already have. No proprietary middleware required. Version-controlled endpoints reduce upgrade risk. And exposing custom DACs via the API means customizations your team built remain reachable to external systems.
In our experience implementing Acumatica integrations, a few patterns consistently create problems down the road:
Over-relying on GI-based OData for high-volume analytical workloads. GIs were designed for operational reporting, not for moving millions of rows into a data warehouse nightly. For high-volume analytical pipelines, DAC-based endpoints or a dedicated data extract pattern will perform better.
Building integrations against the REST API without testing in your Acumatica version. Always validate endpoint behavior in your specific version and customization layer. Standard endpoints behave consistently, but complex customizations can introduce unexpected behavior.
Neglecting field-level security in OData feeds. GI-based feeds respect Acumatica’s field-level access controls — but it’s important to audit which fields your published feeds expose and who has access to the OData endpoint URLs.
Treating integration as a one-time project. Your business evolves, and so does your integration architecture. Build monitoring, alerting, and documentation into every integration from day one.
Overlooking API consumption costs is a common oversight. Acumatica meters API calls against your license tier, and high-frequency integrations or bulk data operations can quickly exhaust your allotment, forcing an unplanned license upgrade that erodes the ROI of your integration investment.
Ready to unlock your Acumatica data?
Whether you’re planning your first Power BI connection to Acumatica or architecting a full data warehouse integration, getting the approach right from the start saves significant time and cost. Our team has deep experience designing and implementing REST API and OData integrations across industries and we’d be glad to walk through your specific use case.
