MYOB and Databricks integration

What moves between them

MYOB serves as the source; Databricks is the read-mostly destination. ml-connector polls MYOB on a schedule you define, reading invoices, purchase orders, supplier and customer payments, GL accounts, and contacts. These records are mapped to Databricks Delta Lake table schemas and written incrementally into the workspace. The flow is one-directional: MYOB to Databricks only. Changes in MYOB are detected via OData LastModified timestamps, so only new or updated records are synced on each run, minimizing API calls and data transfer.

How ml-connector handles it

ml-connector manages MYOB's three-part authentication on every request: it refreshes the OAuth2 bearer token before expiry, presents the API key and company file credentials as headers, and backs off when MYOB returns HTTP 429 rate-limit responses. On the Databricks side, it obtains a service principal bearer token via the workspace or account-level OIDC endpoint and uses it to write metadata and coordinate Delta Lake table operations. Since MYOB has no webhooks, ml-connector polls on a cadence tied to your accounting close calendar and uses OData $filter with LastModified to fetch only changed records since the last sync. Before writing invoices or payments to Databricks, it pre-fetches the GL account registry from MYOB to validate that line-item accounts exist, and it uses BullMQ jobId for deduplication so retried requests do not create duplicate rows. Every record written to Databricks includes the MYOB UID and sync timestamp, and ml-connector maintains an audit trail of all reads and writes.

A real-world example

A growing services firm with offices in Australia and New Zealand uses MYOB for accounting and Databricks for finance analytics. The finance team needs to reconcile invoiced revenue across regions, allocate shared costs to job codes, and forecast cash flow. Before the integration, they exported MYOB reports to CSV at month-end and built pivot tables in Excel, a process that took two days and was error-prone. With MYOB and Databricks connected, invoice and payment data flows into Delta Lake automatically twice daily. Analysts query the tables directly with SQL, build parameterized dashboards in Databricks SQL, and the reconciliation runs in minutes instead of days.

What you can do

• •Poll MYOB invoices, purchase orders, and payments on a schedule, and write them incrementally to Databricks Delta Lake tables.
• •Authenticate MYOB with OAuth2 bearer token, API key, and company file credentials; authenticate Databricks with service principal OAuth2.
• •Detect changes in MYOB using OData LastModified timestamps, so only new or updated records are synced on each run.
• •Map MYOB contacts, GL accounts, and tax codes to Databricks table schemas and validate GL account existence before writing invoice line items.
• •Handle MYOB rate limits with exponential backoff, refresh tokens before expiry, and maintain a full audit trail of every sync.

Questions

Which direction does data move between MYOB and Databricks?

One direction: MYOB to Databricks only. Invoices, payments, GL accounts, and contact records flow from MYOB into Databricks tables. Databricks is a read-mostly analytics platform, not an ERP, so changes in Databricks do not flow back to MYOB.

How does ml-connector handle MYOB's three-part authentication?

ml-connector stores all three credential components (OAuth2 bearer token, API key, and company file username/password) encrypted. On every API request it presents the API key and company file credentials as headers, refreshes the OAuth2 bearer token before the 20-minute expiry, and retries with a fresh token if MYOB returns 401 Unauthorized.

Why does ml-connector use OData LastModified timestamps instead of webhooks?

MYOB does not offer webhooks on the Business API, so ml-connector detects changes by polling with OData $filter on LastModified. This approach is efficient: only records changed since the last sync are fetched, reducing API calls and data transfer volume.