Skip to main content
Question

Is there a way to dynamically query ANY table via API without creating multiple Generic Inquiries?

  • May 29, 2026
  • 2 replies
  • 10 views

I am currently working on an integration where I need to extract data from various tables in Acumatica. Right now, my process heavily relies on using OData via Generic Inquiries (GIs) or configuring Contract-Based REST API Endpoints.

While this works, it is becoming very inconvenient and hard to maintain. Every time there is a new requirement to get data from a new table, I have to go back into Acumatica, create a new GI (or add the table to an existing one), expose it, and publish the project.

I am looking for a much more dynamic approach.

My ideal scenario is to have a single API setup where I can just pass the target Table Name (e.g., SOOrder or InventoryItem) and the Fields I want to retrieve as parameters in the request, and have Acumatica return the data. I want to build/configure it just once and use it universally for any table in the future.

Has anyone encountered this requirement before? Is there any alternative approach, hidden feature, or a more dynamic solution to achieve this without relying on static GIs?

Any ideas, workarounds, or guidance would be greatly appreciated!

Thank you!

2 replies

Dmitrii Naumov
Acumatica Moderator
Forum|alt.badge.img+7
  • Acumatica Moderator
  • May 29, 2026

  • Jr Varsity I
  • May 29, 2026

Adding to Dmitrii's answer (OData v4 direct DAC access). A few practical gotchas:

  1. Permissions: verify behavior in your instance before exposing DACs that contain sensitive data (Vendor with bank info, EPEmployee with personal data, etc.). Test with a low-privilege role to confirm what's filtered.
  2. Computed fields may not materialize. [PXFormula] attributes, fields populated in RowSelected, and projection-only fields can come back null on raw DAC queries. OData reads the cache snapshot, not graph behavior. Anything derived at runtime by graph logic will be missing.
  3. $select is not optional in practice. Without it, the response includes every column on the DAC (50+ on master DACs like ARInvoice, SOOrder, InventoryItem, including audit fields and BLOBs). Always list the fields you need; payload and latency drop significantly.
  4. $expand only follows declared navigation properties. Ad-hoc joins across DACs not related via [PXSelector] or [PXParent] need either client-side stitching or a GI.
  5. Large detail tables hurt. Pulling SOLine or ARTran for a wide date range without $top and a tight $filter is a fast way to time out.

Auth: OAuth2 for production integrations; Basic for quick experiments; cookie auth via /entity/auth/login works but session lifetime is shorter.