Oracle E-Business Suite and BambooHR integration

What moves between them

The flow runs from BambooHR into Oracle E-Business Suite. ml-connector reads BambooHR employees, job information, and employment status, then writes the matching records into the EBS supplier and journal interface tables so EBS reflects BambooHR hires, terminations, and rehires. Department, division, and location values from BambooHR job info are mapped to EBS GL code combinations and operating units, so people records carry valid accounting dimensions. Where compensation feeds the ledger, BambooHR pay rates post into GL_INTERFACE as journal lines for the Journal Import program. BambooHR has no vendors, invoices, POs, or GL accounts of its own, so it is treated as the people source and ml-connector does not write financial documents back into BambooHR.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the BambooHR side it runs the OAuth 2.0 authorization code flow, keeps the subdomain-scoped token URL per customer because BambooHR has no global token endpoint, and refreshes the one-hour access token before it expires. On the EBS side it accepts the full instance URL, obtains a session token on startup, and includes the operating unit org ID and responsibility context on every call, re-authenticating when EBS returns a 401 as the session times out. BambooHR webhooks are lightweight, so each verified event triggers a GET on that employee to fetch current field values before the write. Because EBS cannot push, BambooHR is also polled on a schedule to backfill missed changes. Department and cost center mapping is configured first so every EBS row references a GL code combination and org that already exists. EBS writes insert into an interface table and then run a concurrent program, so a 200 on the POST means the row was staged, not imported; ml-connector triggers the import program and confirms processing. Each interface row carries a unique SOURCE value for duplicate detection, since neither system offers an idempotency key. EBS has no rate limiter, so the connector keeps concurrency low to avoid degrading a shared production system, and BambooHR throttling returns 503 with a Retry-After header that is honored. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized manufacturer with about 600 employees runs Oracle E-Business Suite R12.2 for financials and procurement and uses BambooHR as its HR system of record. Before the integration, HR maintained employee records in BambooHR while a finance analyst keyed the same hires, terminations, and department moves into EBS by hand, and month-end close stalled while labor accounts were reconciled against an org chart that did not match. With Oracle E-Business Suite and BambooHR connected, each employee change in BambooHR flows into EBS automatically, tagged to the right operating unit and cost center, and the duplicate data entry is gone. Close starts with headcount and the people side of the ledger already aligned.

What you can do

• •Sync BambooHR employees, hires, terminations, and rehires into Oracle E-Business Suite interface tables.
• •Map BambooHR department, division, and location to EBS GL code combinations and operating units.
• •Post BambooHR compensation into GL_INTERFACE as journal lines for the Journal Import program.
• •Bridge BambooHR OAuth 2.0 tokens and the EBS session login, refreshing each before it expires.
• •Poll BambooHR on a schedule with retries and a full audit trail, because Oracle EBS cannot be pushed to.

Questions

Which direction does data move between Oracle E-Business Suite and BambooHR?

The flow is BambooHR into Oracle E-Business Suite. Employee records, org structure, and compensation move from BambooHR into the EBS interface tables. BambooHR has no vendors, invoices, or GL accounts of its own, so ml-connector treats it as the people source and does not write financial documents back into it.

How does the integration get data into Oracle EBS when its writes are not instant?

Most EBS writes are two-step. A REST POST inserts a row into an open interface table such as GL_INTERFACE, then a concurrent program like Journal Import loads it into the base tables. ml-connector triggers that import program after staging and confirms the record processed, rather than assuming a successful POST means the record exists in EBS.

How are the two different authentication models handled?

ml-connector runs the BambooHR OAuth 2.0 authorization code flow against the customer's subdomain-scoped token URL and refreshes the one-hour access token automatically. For Oracle EBS it obtains a session token at startup, sends the operating unit and responsibility context on every call, and re-authenticates when the EBS session times out and returns a 401.