Oracle NetSuite and Deel integration

What moves between them

The main flow is from Deel into Oracle NetSuite. After each payroll run, ml-connector reads Deel's payroll GL data and employee cost allocations and posts the labor cost journals into NetSuite's GL, mapped to the matching GL accounts and departments. Employee records flow the same direction so NetSuite headcount reflects Deel hires, terminations, and rehires. Reference data such as departments and cost allocations are validated in both directions. GL postings flow from Deel to NetSuite only; NetSuite does not write payroll entries back to Deel.

How ml-connector handles it

ml-connector stores both credential sets encrypted and presents Deel's OAuth2 bearer token on each request, refreshing when a call returns 401, while handling NetSuite's 60-minute OAuth token lifecycle by refreshing before expiry rather than on-demand. It validates Deel webhook signatures using HMAC-SHA256 on the raw request body before parsing JSON. On the NetSuite side it uses SuiteQL to poll GL accounts and employee records on a schedule tied to your payroll calendar, since NetSuite Event Subscriptions lack native HMAC signatures and rely on IP allowlist instead. Cost allocations from Deel are mapped to NetSuite departments and GL accounts before the labor journal is posted. When Deel rate-limits a request with HTTP 429, ml-connector backs off exponentially and retries. Every record carries an idempotency key so replay on failure does not double-post. Deel API tokens are scoped at creation time with fine-grained resource scopes such as contracts:read and accounting:read, so the token must be provisioned with the exact permissions your flows require.

A real-world example

A mid-sized SaaS company operates Oracle NetSuite for global finance and GL management and uses Deel for payroll and contractor management across eight countries. Before the integration, the finance team downloaded payslips and cost allocations from Deel each month, manually coded them to NetSuite GL accounts and departments, and posted the labor journals by hand. This process took two days and created reconciliation friction when departments or employee allocations changed. With Oracle NetSuite and Deel connected, each payroll run flows automatically into NetSuite's GL, allocated to the correct departments and cost centers. Month-end close starts with labor accounts already complete, and the manual posting step is gone.

What you can do

• •Sync employee records from Deel into Oracle NetSuite, keeping headcount and org structure aligned with hires, terminations, and rehires.
• •Post payroll GL entries and labor cost allocations from Deel into NetSuite's GL each pay cycle, mapped to the correct GL accounts and departments.
• •Validate Deel cost allocations against NetSuite department and GL account masters before posting, so all entries land on live dimensions.
• •Authenticate Deel with OAuth2 bearer token refresh and NetSuite with M2M OAuth client credentials, handling both token models transparently.
• •Verify Deel webhook signatures with HMAC-SHA256, poll NetSuite on your payroll schedule, retry on rate limits and timeouts, and track every record in a full audit trail.

Questions

Does the integration handle Deel webhooks, or does it poll NetSuite?

The integration receives Deel webhook events (contract.created, hris.employee.created, hris.employee.updated, hris.employee.terminated) in real-time and verifies each webhook signature using HMAC-SHA256. On the NetSuite side, it polls GL accounts and employee records on a schedule aligned to your payroll cycle, since NetSuite Event Subscriptions do not include native HMAC signatures.

How does ml-connector handle Deel's OAuth2 tokens and API token scopes?

ml-connector stores Deel credentials encrypted and refreshes OAuth2 access tokens when calls return 401, respecting the 30-day access token and 90-day single-use refresh token windows. Because Deel API tokens are scoped at creation time with fine-grained permissions such as contracts:read or accounting:read, the token must be provisioned with the scopes your flows require. For M2M flows, use a long-lived Organization Token; for user-scoped flows, use a Personal Token.

What happens when Deel rate-limits a request or a GL posting fails in NetSuite?

When Deel returns HTTP 429 Too Many Requests, ml-connector backs off exponentially and retries. Each GL posting carries an idempotency key, so if a NetSuite call fails and is replayed, the entry posts only once. Every attempt is logged in the audit trail so you can trace the flow of each transaction through both systems.