Which direction does data flow between Oracle Fusion and Deel?

The main flow is Deel into Oracle Fusion. Payroll invoices, costs, and employee records move from Deel into Oracle Fusion, while cost centers and GL accounts are validated on both sides. Deel data is read-only to Oracle Fusion, so ml-connector does not write payroll entries back into Deel.

How does the integration handle Deel's API token scopes and rate limiting?

Deel API tokens are scoped at creation time with fine-grained resource permissions such as contracts:read, people:read, and accounting:read. ml-connector requires a token with the necessary scopes for the records you want to sync. When Deel returns HTTP 429, ml-connector backs off exponentially and retries within the Retry-After window so rate limits do not block the flow.

Why does ml-connector poll both systems instead of relying on webhooks?

Oracle Fusion has no direct outbound webhooks without Oracle Integration Cloud middleware, so polling is required on the Oracle side. Although Deel supports webhooks for real-time events, ml-connector polls both systems on the same schedule tied to your payroll cadence to ensure costs and headcount stay synchronized without requiring separate webhook infrastructure.

Oracle Fusion Cloud ERPDeel

Oracle Fusion Cloud ERP and Deel integration

Oracle Fusion Cloud ERP runs your accounting and supply chain. Deel runs your global payroll and contractor management. Connecting them keeps labor costs flowing into your general ledger and your employee records aligned. Deel invoices and payslips map to Oracle Fusion GL accounts and cost centers on a schedule you control, and worker changes in Deel sync to Oracle Fusion to keep headcount in agreement. ml-connector bridges the two platforms and moves the data reliably.

How Oracle Fusion Cloud ERP works

Oracle Fusion Cloud ERP exposes invoices, payments, suppliers, purchase orders, customers, receivables invoices, journal batches, headers, lines, and GL accounts through REST APIs against a customer-specific pod URL on https://{pod}.fa.{region}.oraclecloud.com. The API uses OAuth 2.0 Client Credentials or Authorization Code grants and accepts OData-style query parameters such as LastUpdateDate filters to poll for new or changed records. Oracle Fusion has a Business Events system but it requires Oracle Integration Cloud middleware to push events to external URLs, so finance records are read by polling the REST API every 5 to 15 minutes. PATCH operations on invoices update only header attributes; GL account data is typically static reference setup.

How Deel works

Deel exposes contracts, people, invoices, worker invoices, payslips, onboarding records, and payroll inputs through REST APIs on https://api.letsdeel.com/rest/v2. Authentication uses Bearer tokens (Organization or Personal tokens with fine-grained resource scopes) or OAuth2 Authorization Code with 30-day access token expiry and 90-day refresh token expiry. Deel supports real-time webhooks for events such as contract.created, employee.created, employee.updated, and employee.terminated, with HMAC-SHA256 signature verification on the request. The API returns 429 Too Many Requests with a Retry-After header when rate-limited. Deel has no purchase orders, vendors, or GL account master; GL account data is embedded in payment and invoice payloads.

What moves between them

The main flow is Deel into Oracle Fusion. After each payroll run, ml-connector reads Deel invoices and worker payslips, extracts GL postings and cost allocations, and creates corresponding journal entries in Oracle Fusion's general ledger, mapped to the matching GL accounts and cost centers. Employee records flow the same direction so Oracle Fusion headcount reflects Deel hires, terminations, and updates. Cost centers and departments are aligned so payroll allocations land on valid Oracle Fusion dimensions. Deel invoice data is read-only to the ERP; ml-connector does not write payroll entries back into Deel.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Oracle Fusion side, it refreshes OAuth2 bearer tokens when a call returns 401 and polls the REST API using LastUpdateDate filters to detect new and modified records since the last poll. On the Deel side, it accepts both API tokens and OAuth2 credentials, verifies webhook signatures using HMAC-SHA256 before processing events, and refreshes OAuth2 tokens when they approach expiry. Because Oracle Fusion has no outbound webhooks without middleware, ml-connector polls both systems on a schedule. Deel API tokens are scoped to fine-grained resources, so the integration token must have scope for contracts, people, invoices, and payslips. When Deel returns 429, ml-connector backs off exponentially and retries, and it tracks OAuth2 token expiry on both sides to prevent outages. Cost centers and GL accounts are mapped first, so every payroll journal line references an account and dimension that already exists in Oracle Fusion. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized professional services firm runs Oracle Fusion Cloud ERP for accounting and project management, and uses Deel for payroll across contractors and full-time employees in 12 countries. Before the integration, finance exported payroll summaries from Deel every month and manually coded journal entries into Oracle Fusion, matching each entry to the correct project cost center. With Oracle Fusion and Deel connected, each month's payroll run automatically posts labor costs into the general ledger allocated to the correct projects, contractor invoices flow in alongside employee costs, and headcount changes sync overnight. Month-end close starts with labor accounts already reconciled and coded, eliminating the manual entry step.

What you can do

Post Deel payroll invoices and costs into Oracle Fusion's general ledger, allocated to the correct cost centers and projects.
Keep Oracle Fusion employee records aligned with Deel hires, terminations, and contract updates.
Map Deel cost centers and allocation data to Oracle Fusion GL accounts and cost center dimensions.
Authenticate Oracle Fusion with OAuth2 bearer tokens and Deel with API tokens or OAuth2, handling token refresh on both sides.
Verify Deel webhook signatures with HMAC-SHA256, poll Oracle Fusion on a schedule, and replay failed records with a full audit trail.

Questions

Which direction does data flow between Oracle Fusion and Deel?: The main flow is Deel into Oracle Fusion. Payroll invoices, costs, and employee records move from Deel into Oracle Fusion, while cost centers and GL accounts are validated on both sides. Deel data is read-only to Oracle Fusion, so ml-connector does not write payroll entries back into Deel.
How does the integration handle Deel's API token scopes and rate limiting?: Deel API tokens are scoped at creation time with fine-grained resource permissions such as contracts:read, people:read, and accounting:read. ml-connector requires a token with the necessary scopes for the records you want to sync. When Deel returns HTTP 429, ml-connector backs off exponentially and retries within the Retry-After window so rate limits do not block the flow.
Why does ml-connector poll both systems instead of relying on webhooks?: Oracle Fusion has no direct outbound webhooks without Oracle Integration Cloud middleware, so polling is required on the Oracle side. Although Deel supports webhooks for real-time events, ml-connector polls both systems on the same schedule tied to your payroll cadence to ensure costs and headcount stay synchronized without requiring separate webhook infrastructure.

Connect Oracle Fusion Cloud ERP and Deel

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started