Acumatica and Databricks integration

What moves between them

Data moves from Acumatica into Databricks. On each scheduled run, ml-connector reads new and changed Acumatica vendors, AP bills, purchase orders, payments, GL accounts, and journal transactions, then writes them into matching Delta Lake tables under a Unity Catalog schema using the SQL Statement Execution API. A high-water mark on LastModifiedDateTime keeps each run incremental so only records changed since the last sync are pulled. The flow is one-directional: Databricks is a read-and-query destination for analytics, and ml-connector does not write financial records back into Acumatica.

How ml-connector handles it

ml-connector stores both credential sets encrypted and presents the correct bearer token to each system on every call. On the Acumatica side it accepts the full instance URL and endpoint version per customer, since the version is baked into every path and a mismatch returns 404, and it wraps each field value in the value object that the Contract-Based REST API requires. On the Databricks side it requests a service principal token, refreshes it before the one-hour expiry rather than waiting for a 401, and loads rows by submitting SQL through the Statement Execution API and polling the statement id until it finishes, since table data cannot be written through plain REST. Each load carries a Jobs-style idempotency token so a retried statement returns the existing run instead of double-inserting. Acumatica throttles once the per-minute request count passes half the licensed limit and returns 429, and Databricks enforces fixed per-group rate limits, so ml-connector backs off with jitter on both. Every record carries a full audit trail and can be replayed if a load fails.

A real-world example

A mid-sized distribution company runs Acumatica Cloud ERP for purchasing, AP, and the general ledger across several warehouses, and its data team runs Databricks for company-wide reporting. Before the integration, an analyst exported AP and GL data from Acumatica to spreadsheets each week and uploaded them into Delta Lake by hand, so spend dashboards were always days behind and broke whenever a column shifted. With Acumatica and Databricks connected, AP bills, purchase orders, payments, and GL journal lines land in Delta Lake on a nightly schedule, mapped to stable table columns. Spend and margin dashboards refresh against current finance data, and the manual export step is gone.

What you can do

• •Land Acumatica AP bills, purchase orders, payments, GL accounts, and journal transactions in Delta Lake tables on a schedule you set.
• •Run incremental loads using a LastModifiedDateTime high-water mark so each run pulls only changed records.
• •Write rows into Databricks through the SQL Statement Execution API, since table data is not writable over plain REST.
• •Authenticate Acumatica with OAuth 2.0 against its instance identity server and Databricks with an OAuth 2.0 service principal token.
• •Refresh the one-hour Databricks token before expiry and back off on Acumatica and Databricks rate limits, with a full audit trail on every record.

Questions

Which direction does data move between Acumatica and Databricks?

Data moves from Acumatica into Databricks. Finance records such as AP bills, purchase orders, payments, GL accounts, and journal transactions read out of Acumatica and land in Delta Lake tables for analytics. Databricks is the query and reporting destination, so ml-connector does not write financial records back into Acumatica.

How does ml-connector write records into Databricks if the REST API only manages metadata?

The Databricks REST API manages table metadata, while actual rows are written by running SQL against a SQL warehouse. ml-connector uses the SQL Statement Execution API to submit insert statements and polls the returned statement id until the load finishes. Each statement carries an idempotency token so a retried load returns the existing run instead of inserting duplicate rows.

What does the Acumatica endpoint version requirement mean for setup?

Acumatica bakes the endpoint version into every API path, and a version that does not match the running ERP release returns a 404 immediately. ml-connector accepts the instance URL and endpoint version per customer and validates entity paths against that instance. Because Acumatica cloud is read primarily by polling, it pulls changed finance records on a schedule using the LastModifiedDateTime filter rather than relying on a push.