Oracle JD Edwards and Deel integration

What moves between them

Employee and contractor records flow from Deel into Oracle JD Edwards. When a Deel webhook fires for contract.created or hris.employee.created, ml-connector writes a new address book entry (F0101) in JD Edwards if the person does not exist. On hris.employee.terminated, the JD Edwards record is marked inactive. Payroll cost data flows one direction from Deel into JD Edwards; payroll-inputs such as bonuses and deductions trigger journal entry batches (F0911Z1) into the GL, allocated to cost centers that match Deel cost allocation tags. Employee lifecycle events arrive via webhook; full payroll syncs may run on a cadence tied to your payroll period.

How ml-connector handles it

ml-connector maintains two separate credential sets: a JD Edwards service account with username and password (generating session tokens via /jderest/v2/tokenrequest every 25 minutes before expiry), and a Deel API token scoped with people:read, contracts:read, accounting:read, and payroll-inputs:write permissions. Deel webhooks are registered pointing to ml-connector ingest endpoint, which verifies the HMAC-SHA256 signature against the raw request body, parses the event, and decides whether to immediately upsert JD Edwards records or queue the payload for batch processing on the next payroll sync. JD Edwards batch writes use orchestration endpoints with Deel-supplied IDs as the dedup key to prevent duplicate journal entries if a webhook retries. Cost centers are mapped during setup by listing Deel cost-allocation dimensions and matching them to JD Edwards GL account / cost center pairs; when a payroll-input arrives for a cost center not yet mapped, ml-connector alerts the operator rather than guessing. JD Edwards tokens can be invalidated on AIS Server restart, so ml-connector retries 401 responses by re-authenticating immediately. Deel API returns 429 rate-limit responses with Retry-After headers; ml-connector backs off exponentially and retries.

A real-world example

A staffing firm uses Deel for contractor payroll across Europe and Asia and Oracle JD Edwards for consolidated financial reporting to their corporate office. Each month, the finance team manually exported contractor invoices from Deel, re-entered labor costs by country into JD Edwards GL accounts, then reconciled headcount between systems by hand, a process prone to delays and errors during month-end close. With Deel and Oracle JD Edwards connected, contractor hires and terminations in Deel automatically appear in the JD Edwards address book, payroll invoices flow into the GL allocated to the correct country cost centers, and reconciliation happens automatically. Month-end close now starts with labor accounts already validated against contractor records.

What you can do

• •Sync Deel contracts and employees into Oracle JD Edwards address book (F0101) on creation or termination, keeping employee records current across systems.
• •Flow Deel payroll cost data into Oracle JD Edwards GL (F0911) allocated to cost centers, with full audit trail on every journal entry.
• •Map Deel cost-allocation dimensions to Oracle JD Edwards GL accounts and cost centers, preventing misallocated labor costs.
• •Handle Oracle JD Edwards token lifecycle and session refresh, and verify Deel webhook signatures using HMAC-SHA256.
• •Retry failed GL postings with exponential backoff and provide replay capability if a downstream GL entry fails to save.

Questions

How often do employee and payroll records sync between Deel and Oracle JD Edwards?

Employee lifecycle events (hires, terminations) flow via Deel webhooks in near-real-time when ml-connector receives them. Payroll cost data can flow on a weekly or monthly cadence tied to your payroll schedule. ml-connector can ingest Deel webhooks immediately and queue journal entries for batch posting if your Oracle JD Edwards policy prefers consolidated GL entries at month-end.

Does ml-connector handle the differences between Oracle JD Edwards on-premises token auth and Deel API token scopes?

Yes. ml-connector manages JD Edwards session tokens separately from Deel API tokens, refreshing JD Edwards tokens every 25 minutes before their 30- to 60-minute lifetime expires. Deel API tokens are scoped at creation time with fine-grained permissions (people:read, contracts:read, accounting:read, payroll-inputs:write) and require no refresh. Both credential sets are stored encrypted and rotated on demand.

What happens if an Oracle JD Edwards GL posting fails or a Deel webhook arrives out of order?

Every record carries a full audit trail showing when it arrived, what it mapped to, and whether it posted. If a GL entry fails, ml-connector surfaces the error and allows replay of the journal entry batch with the same Deel ID (dedup key) so you do not create duplicate GL postings. Webhook events are processed in order; if a later event arrives before an earlier one, ml-connector queues it and retries in sequence.