Acumatica and Looker integration

What moves between them

The primary flow runs from Looker into Acumatica. On each scheduled run, ml-connector runs the configured Looker queries, such as a reconciled GL summary, an approved-vendor list, or a period allocation built in LookML from warehouse data, and writes the results into Acumatica as journal transactions or reference records mapped to the right accounts and dimensions. In the supporting direction, ml-connector reads new and changed Acumatica vendors, bills, payments, and GL entries since the last high-water mark so the warehouse that backs those Looker reports stays current. Cadence is set per flow, from intraday to a nightly run, and Looker is treated as a read source for finance figures rather than a place to write transactions.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Acumatica side it accepts the full tenant URL and the endpoint version per customer, requests an OAuth 2.0 token, and refreshes it when a call returns 401, wrapping every field value as a {value: ...} object so Acumatica does not reject the write with a 400. On the Looker side it logs in with the API3 client id and secret, caches the one-hour token, sends it in the token scheme rather than Bearer, and re-authenticates transparently on a 401, since Looker issues no refresh token. Because Looker has no change events, the connector polls it on a schedule and runs each query by model, Explore, and field names from the customer LookML, paging by offset and using async query tasks when a result set exceeds the 5000-row cap. Query columns are mapped to Acumatica GL accounts and dimensions first, so each posted journal line lands on a valid account. Looker returns HTTP 429 past its per-key request limit and Acumatica returns 429 past its licensed threshold, so the connector backs off with jitter and retries either side. Before creating an Acumatica document it checks for an existing record by natural key, because neither API offers an idempotency key, and every record carries a full audit trail and can be replayed if a write fails.

A real-world example

A mid-sized distribution company runs Acumatica for procurement, AP, and the general ledger across several warehouses, and its analytics team models that data in a warehouse and reports on it through Looker. The accounting team had built a reconciled monthly allocation in LookML that splits shared overhead across cost centers, but every period someone exported the Looker results to a spreadsheet and keyed the allocation journal into Acumatica by hand, which delayed close and introduced transcription errors. With Acumatica and Looker connected, ml-connector runs that Looker query at period end and posts the allocation as a journal transaction in Acumatica against the correct accounts and dimensions, while keeping the warehouse fed with the latest Acumatica GL data. The manual export and re-keying step is gone and close starts from numbers that already tie out.

What you can do

• •Run Looker queries that summarize warehouse finance data and post the results into Acumatica as journal transactions or reference records.
• •Read Acumatica vendors, bills, payments, and GL entries on a schedule to keep the warehouse behind Looker current.
• •Map Looker query columns to Acumatica GL accounts and dimensions so every posted line lands on a valid account.
• •Bridge Acumatica OAuth 2.0 and Looker's one-hour API3 login token, re-authenticating each side on a 401.
• •Poll on the cadence you set, with offset paging, async query tasks for large extracts, retries, and a full audit trail on every record.

Questions

Can ml-connector write invoices or GL accounts into Looker?

No, and that is by design. Looker is a BI layer over a data warehouse and has no native vendor, invoice, purchase order, or GL account object, so there is nothing to write those records into. Instead ml-connector runs Looker queries against data modeled in LookML and moves the results into Acumatica, which is the system of record for finance transactions.

Which direction does data move between Acumatica and Looker?

The primary flow is Looker into Acumatica: ml-connector runs Looker queries that aggregate warehouse data, such as a reconciled GL summary or a period allocation, and posts the results into Acumatica as journal transactions or reference records. In the supporting direction it reads Acumatica finance records on a schedule so the warehouse those Looker reports run against stays current. It does not push transactions into Looker.

Does the connector wait for Looker to push events, or does it poll?

It polls. Looker has no change-event webhooks; its Scheduled Plans only deliver query results on a cron, and the Action Hub fires only when a user clicks a data action. So ml-connector runs the configured Looker queries on a schedule you set, caches the one-hour login token, and re-authenticates on a 401 since Looker issues no refresh token.