Oracle Fusion Cloud ERP and BambooHR integration

What moves between them

The main flow moves from BambooHR into Oracle Fusion Cloud ERP. When an employee is hired, updated, or terminated in BambooHR, a webhook notification triggers ml-connector to fetch the full employee record and post it to Fusion, mapped to the matching department and cost center. Compensation changes in BambooHR flow similarly, updating the Fusion GL accounts tied to labor costs. Job title and employment status changes in BambooHR update the corresponding fields in Fusion employee records. The integration polls Fusion cost centers and GL accounts to validate mappings before posting, ensuring payroll and HR data land on valid Fusion accounts. Reference data such as departments, job codes, and cost centers are aligned in both directions so Fusion headcount reflects BambooHR state.

How ml-connector handles it

ml-connector stores both OAuth credential sets encrypted and refreshes each independently when a call returns 401. On the BambooHR side, it receives webhooks at a registered HTTPS endpoint, validates the SHA-256 HMAC signature with the webhook secret, and fetches the full employee record via the BambooHR REST API since webhook payloads are lightweight notifications only. Webhook field queries explicitly enumerate required fields to stay within the 400-field-per-request limit. On the Fusion side, it polls GL accounts and cost centers before posting employee data, since Fusion PATCH operations on invoices only update header attributes and do not cascade defaults automatically. BambooHR rate limits are not documented but return 503 Service Unavailable with an optional Retry-After header, so ml-connector backs off and retries. Both systems issue 1-hour tokens, so ml-connector tracks expiry and refreshes before a call fails. Compensation and job info are versioned history tables in BambooHR, not single-value fields, so ml-connector stores the latest version in Fusion and tracks changes for audit. Every record carries a full audit trail and can be replayed if a downstream Fusion post fails.

A real-world example

A mid-sized services company runs Oracle Fusion Cloud ERP for finance and procurement, and uses BambooHR for HR, payroll, and benefits across three offices. Before the integration, the finance team received biweekly headcount reports from HR, manually reconciled new hires and terminations in Fusion departments and cost centers, and updated labor GL accounts by hand. Payroll journals from the accounting system did not match HR headcount until mid-month close. With BambooHR and Fusion connected, each new hire in BambooHR automatically flows into the matching Fusion department and cost center, terminations update Fusion employment status records, and compensation changes post to the correct GL accounts. Month-end close starts with HR and finance headcount already reconciled, and manual reconciliation is eliminated.

What you can do

• •Sync employee records from BambooHR into Oracle Fusion Cloud ERP, mapping to departments and cost centers.
• •Receive employee.created, employee.updated, and employee.deleted webhooks from BambooHR and fetch full employee data on each event.
• •Map BambooHR compensation changes to Oracle Fusion GL accounts and post updates to labor cost tracking.
• •Authenticate with OAuth 2.0 on BambooHR using per-customer subdomain token endpoints, and on Oracle Fusion using OCI Identity Domain.
• •Poll Fusion GL accounts and cost centers to validate mappings before posting, with retries, HMAC signature validation, and full audit trails.

Questions

Which direction does data move between Oracle Fusion Cloud ERP and BambooHR?

The main flow is from BambooHR into Oracle Fusion Cloud ERP. Employee records, job info, and compensation data move from BambooHR into Fusion, mapped to Fusion departments and cost centers. Reference data such as departments and cost centers are aligned in both directions. Fusion GL accounts are read-only in this integration, so ml-connector does not write financial transactions back to BambooHR.

How does the integration handle BambooHR's per-subdomain OAuth endpoints and HMAC webhook signatures?

ml-connector stores the BambooHR company domain and refreshes OAuth tokens at the customer-specific token endpoint (e.g., https://{companyDomain}.bamboohr.com/token.php). On webhook receipt, it validates the SHA-256 HMAC signature against the registered webhook secret before processing the event. If validation fails, the webhook is rejected and logged for audit.

Why does the integration poll Oracle Fusion cost centers and GL accounts before posting employee data?

Oracle Fusion GL accounts and cost centers are managed via setup, not transactional API, and PATCH operations do not cascade defaults automatically. ml-connector validates that the target cost center and GL account exist in Fusion before posting employee data, so payroll and HR records land on valid accounts and month-end reconciliation is clean.