Skip to main content
Question

Best approach integration Web Service Endpoints (Generic Inquiry) vs OData

  • April 28, 2026
  • 4 replies
  • 50 views

Best approach for integration — Web Service Endpoints (Generic Inquiry) vs OData?

Hi all,

I'd like some advice on the best way to build an integration with Acumatica. What's the recommended approach — going through standard Web Service Endpoints (via Generic Inquiry or standart endpoint) or using OData?

What I need to retrieve:

  • Account balances as of a given date
  • Transactions (including base currency) for a specific period
  • Currency exchange rates for a specific period

What I've tried so far:

I created several Generic Inquiries and exposed them through a Web Service Endpoint.

When I tested it by pulling transactions(via standart JournalTransaction)  for a single month (to get the line details I had to pass $expand), execution time was around 14–60 seconds. Our demo instance originally had 16 GB of RAM; after bumping it up to 64 GB, performance improved to around 5–15 seconds — but that's still pretty slow for demo ~155 transaction per month.

2019-01 [2019-01-01 -> 2019-02-01]: 359 transactions in 9.74s
2019-02 [2019-02-01 -> 2019-03-01]: 334 transactions in 4.70s
2019-03 [2019-03-01 -> 2019-04-01]: 358 transactions in 5.82s
2019-04 [2019-04-01 -> 2019-05-01]: 364 transactions in 4.64s
2019-05 [2019-05-01 -> 2019-06-01]: 348 transactions in 4.71s
2019-06 [2019-06-01 -> 2019-07-01]: 342 transactions in 5.44s
2019-07 [2019-07-01 -> 2019-08-01]: 401 transactions in 5.41s
2019-08 [2019-08-01 -> 2019-09-01]: 333 transactions in 5.49s
2019-09 [2019-09-01 -> 2019-10-01]: 333 transactions in 5.55s
2019-10 [2019-10-01 -> 2019-11-01]: 368 transactions in 5.89s
2019-11 [2019-11-01 -> 2019-12-01]: 313 transactions in 6.87s
2019-12 [2019-12-01 -> 2020-01-01]: 407 transactions in 6.92s
2020-01 [2020-01-01 -> 2020-02-01]: 445 transactions in 10.10s
2020-02 [2020-02-01 -> 2020-03-01]: 378 transactions in 8.95s
2020-03 [2020-03-01 -> 2020-04-01]: 386 transactions in 8.87s
2020-04 [2020-04-01 -> 2020-05-01]: 429 transactions in 9.55s
2020-05 [2020-05-01 -> 2020-06-01]: 442 transactions in 12.04s
2020-06 [2020-06-01 -> 2020-07-01]: 438 transactions in 10.85s
2020-07 [2020-07-01 -> 2020-08-01]: 395 transactions in 9.72s
2020-08 [2020-08-01 -> 2020-09-01]: 631 transactions in 14.86s
2020-09 [2020-09-01 -> 2020-10-01]: 452 transactions in 12.93s
2020-10 [2020-10-01 -> 2020-11-01]: 441 transactions in 16.29s
2020-11 [2020-11-01 -> 2020-12-01]: 437 transactions in 30.35s
2020-12 [2020-12-01 -> 2021-01-01]: 438 transactions in 29.15s
2021-01 [2021-01-01 -> 2021-02-01]: 409 transactions in 13.67s
2021-02 [2021-02-01 -> 2021-03-01]: 395 transactions in 12.21s
2021-03 [2021-03-01 -> 2021-04-01]: 370 transactions in 14.37s
2021-04 [2021-04-01 -> 2021-05-01]: 356 transactions in 13.89s
2021-05 [2021-05-01 -> 2021-06-01]: 372 transactions in 43.54s
2021-06 [2021-06-01 -> 2021-07-01]: 338 transactions in 14.13s
2021-07 [2021-07-01 -> 2021-08-01]: 374 transactions in 14.45s
2021-08 [2021-08-01 -> 2021-09-01]: 339 transactions in 15.49s

Then I tried exporting the same data via OData, and it ran significantly faster.

My questions:

  1. Why are standard Web Service Endpoints so slow compared to OData?
  2. Is there anything I can do to speed up the Web Service Endpoint approach, if it's possible at all?
  3. Which approach would you recommend for this kind of integration?

One more thing — could the issue be related to the fact that I'm using a custom Web Service Endpoint? It was extended from the base endpoint and contains all the standard endpoints as well.

 

Thanks in advance for any insights!

4 replies

Forum|alt.badge.img+1
  • Semi-Pro I
  • April 30, 2026

For your scenario, the performance difference you’re seeing is expected.

They go through the full business logic layer (Graphs, events, validations)

$expand is especially expensive because it loads related data via multiple queries

Designed for transactional operations, not high-volume data extraction

For your requirements:

 

Account balances / Transactions / Exchange rates

Use OData or GI-based OData (best performance)

Create/update documents

Use Web Service Endpoints


KrunalDoshi
Varsity III
Forum|alt.badge.img+1
  • Varsity III
  • May 11, 2026

Hi ​@andriikozii,

Considering your requirements, I would suggest adding only those entity or GI what you need instead of using default endpoint. If you are using GI, then add only those columns which you need and get the data by pagination. You can always loop through while retrieving the data using top and skip. You can also make sure that connection between integration is kept open for longer period. You can always logout and log back in as needed. This should definitely improve performance. 

Hope this helps!


Forum|alt.badge.img+1

Hi ​@andriikozii 

 

Yes — your approach is correct and is generally considered the best practice for high-volume Acumatica financial integrations.

 

Recommended Architecture : 

  • GL Transactions: Flat GI-based REST endpoint
  • Account Balances: GI or OData
  • Currency Rates: Lightweight GI/REST entity
  • Writes/Posting: Standard REST endpoints only

 

Why :

Standard REST + heavy $expand is slower because it loads:

  • graphs
  • caches
  • business logic
  • nested entities

GI-based endpoints are much lighter and scale better for read-heavy integrations.

 

Best Practice :

  • Avoid deep $expand
  • Avoid bloated Default endpoints
  • Use a dedicated lightweight integration endpoint
  • Keep responses flat and paged

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

@aryanjadhav50 this looks like an AI response to be honest. If it is one, please mark it explicitly as such, as it’s required according to the Community policy. 

 

Also, I don’t think it’s a correct recommendation. 

E.g. 

  • Avoid bloated Default endpoints

It’s not the best practice. When possible you should use the default endpoint.

 

 

 

Recommended Architecture : 

  • GL Transactions: Flat GI-based REST endpoint

Why create a REST endpoint for a GI when it can be accessed with OData? That’s not a best practice.