Oracle NetSuite and Rippling integration

What moves between them

The main flow runs from Rippling into Oracle NetSuite. After each payroll run, ml-connector reads Rippling's general ledger entries and posts them into NetSuite's accounts, allocated to departments and cost centers that exist in both systems. Employee records, departments, and accounting dimensions flow bidirectionally: Rippling hires and terminations sync into NetSuite, and NetSuite department and location changes sync back to Rippling so headcount and cost allocations remain in agreement. Payroll GL entries are read-only in Rippling, so ml-connector never writes financial data back to payroll.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For Oracle NetSuite, it refreshes OAuth tokens every 55 minutes (token lifetime is 60 minutes) and accepts the account ID (with or without sandbox suffix) to construct the base URL. For Rippling, it authenticates with an API key on every request or maintains an OAuth token for App Shop integrations. Since Oracle NetSuite Event Subscriptions lack native HMAC signing, ml-connector validates webhook authenticity using IP allowlist or shared secrets instead. Because Rippling API-key integrations do not support webhooks, ml-connector polls the company activity log or updated_at timestamps on the employees endpoint on a schedule tied to your payroll calendar. Departments and accounting dimensions are mapped and validated first, ensuring every payroll GL line references an account and cost center that exists in NetSuite. Rippling API calls support Idempotency-Key headers for safe retries, and ml-connector tracks token expiry and enforces them on every request. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized services company runs Oracle NetSuite for accounting and operations, and uses Rippling for payroll, HR, and IT management across three offices and multiple cost centers. Before the integration, payroll exports from Rippling were manually imported into NetSuite each pay period, followed by hand-coded GL entries to assign labor costs to the correct departments and locations. Reconciliation at month-end close required chasing data between the two systems and correcting misaligned cost centers. With Oracle NetSuite and Rippling connected, each payroll run's GL entries post into NetSuite automatically, allocated to the correct department and location, and employee changes keep both systems in sync. Month-end close begins with labor accounts already reconciled, and the manual import and entry step is eliminated.

What you can do

• •Sync employees, departments, and accounting dimensions between Rippling and Oracle NetSuite in both directions so payroll allocations land on valid accounts.
• •Post Rippling payroll GL entries into Oracle NetSuite's general ledger after every pay run, mapped to the correct departments and cost centers.
• •Authenticate Oracle NetSuite with OAuth 2.0 client credentials and Rippling with API key bearer tokens, and refresh NetSuite tokens every 55 minutes.
• •Poll Rippling company activity or employee timestamps (since webhooks are restricted to App Shop integrations) on a schedule tied to your payroll calendar, with retry and audit trail support.
• •Keep headcount, cost allocations, and department hierarchies in agreement across both systems without manual export and re-entry.

Questions

Which direction does data flow between Oracle NetSuite and Rippling?

The main flow is Rippling into Oracle NetSuite. Payroll GL entries and employee records move from Rippling into NetSuite, while departments, locations, and accounting dimensions sync in both directions. Payroll GL entries are read-only in Rippling, so ml-connector does not write financial data back into payroll. This design keeps NetSuite the source of truth for accounts and dimensions while Rippling drives the payroll posting schedule.

Does ml-connector use Rippling webhooks or polling?

Rippling webhooks are only available to App Shop integrations with OAuth. Direct API-key integrations (the typical mode) do not receive webhooks, so ml-connector polls the company activity log or employees endpoint using updated_at filtering on a schedule tied to your payroll calendar. This avoids missed events while remaining efficient.

How does ml-connector handle OAuth token refresh for Oracle NetSuite?

Oracle NetSuite OAuth tokens are valid for 60 minutes and do not include a refresh token in the M2M client credentials flow. ml-connector refreshes the token every 55 minutes proactively, tracks expiry, and includes the fresh bearer token on every REST call to avoid 401 responses during request sequences. Sandbox accounts require the _SB suffix in the account ID (e.g., 1234567_SB1).