Choosing the wrong integration method on an Oracle Fusion project is one of the most common mistakes that causes performance issues, failed migrations, and unnecessary rework. HDL, FBDI, and REST APIs are not interchangeable — each is designed for a specific volume, module, and latency requirement. Most guides stop at three tools. This one covers four, including HSDL, which is missing from most comparison articles but used in almost every HCM implementation for post go-live operations. The decision framework comes down to two questions: what module are you loading into, and how much data are you moving at once?
Why the Method Matters More Than the Technology
One of the most common design mistakes on Oracle Fusion projects is selecting an integration method based on what the team is most familiar with rather than what the requirement actually calls for.
Using REST APIs to load 50,000 employee records at go-live creates thousands of individual API calls with rate limits, timeout risks, and near-zero visibility into which records failed. Using HDL for a real-time hire-to-activate scenario means the new employee doesn't appear in the system until the next batch cycle runs.
The method has to match the requirement. The two questions that drive the decision are:
- What module are you loading into — HCM, ERP, SCM, or CX?
- How much data are you loading, and does it need to be available immediately?
Understanding the Four Methods
HDL — HCM Data Loader
HDL is Oracle's recommended bulk loading framework specifically for Oracle Fusion HCM. It is designed to load large volumes of HCM data efficiently, reliably, and with full control over sequencing and error handling.
What it can load:
- Workers, persons, and work relationships
- Assignments, jobs, positions, and grades
- Organizations, departments, and legal employers
- Element entries and payroll data
- Documents of record, images, and binary attachments
- Security users and role assignments
- Learning, talent, and absence data
How it works — the two-phase process:
HDL doesn't load data in a single step. It runs in two phases:
- Import phase — validates the syntax of the file. If any file format or metadata errors exist, they are reported here. The Load phase does not begin until Import succeeds.
- Load phase — validates the data against business rules and loads it into application tables. Object-level errors are logged separately so individual records can be fixed and resubmitted without reloading everything.
This staged approach is what makes HDL reliable for large volumes — errors are isolated and traceable rather than causing a silent partial load.
File format and instructions:
HDL uses pipe-delimited .dat files zipped into a .zip archive. Each file contains METADATA lines that define the structure and data lines that use one of four instructions:
- MERGE — creates the record if it doesn't exist, updates it if it does. This is the recommended instruction for most loads since you don't need to know in advance whether the record already exists.
- CREATE — explicitly creates a new record
- DELETE — removes a record (not supported on all business objects — check the View Business Objects page)
- END_DATE — ends a date-effective record
Key technical capabilities:
- Multi-threading — the number of processing threads is configurable from the Configure HCM Data Loader task, allowing large loads to be distributed across multiple parallel threads for faster processing
- Automation — HDL can be fully automated via web services or REST APIs, making it suitable for recurring scheduled integrations through OIC without any manual user intervention
- Source Key identification — Oracle recommends using SourceSystemId and SourceSystemOwner as the primary way to identify records across all implementations. Source keys allow you to reference and update records using your own system identifiers, and they are essential for updates where user keys alone aren't sufficient
- Binary data — images and documents can be included in the same ZIP archive alongside the
.datfiles, linked to the records being loaded
What HDL is not for: HDL is HCM-only. It cannot load ERP data such as invoices, suppliers, journals, or fixed assets. For those, FBDI is the appropriate tool.
HSDL — HCM Spreadsheet Data Loader
HSDL is the tool most comparison guides don't mention — and the one that shows up on almost every HCM implementation for post go-live operations.
HSDL is built on top of HDL. Internally, it converts spreadsheet data into HDL format and runs through the same HDL processes underneath. The difference is the interface and the intended user.
What makes HSDL different from HDL:
- Uses Excel spreadsheet templates with drop-down menus, date pickers, and searchable lists (LOVs) — no pipe-delimited flat files
- Provides real-time, on-screen validation as data is entered, rather than reporting errors after the upload completes
- Designed for business users and HR analysts, not integration specialists
- Templates are configured by an administrator, then shared with business users who perform the actual data entry and upload
- Business users don't need to know which fields are keys or what code values to supply — HSDL surfaces this through the template design
Where HSDL is typically used:
- Post go-live operational updates by HR teams (address changes, email updates, position reassignments)
- Smaller volume loads where business users own the data — roughly 50 to 5,000 rows
- Scenarios where real-time validation during entry reduces rework after the fact
- Cases where business users need access to update data they don't have direct UI access to
Where HSDL is not appropriate:
- Initial go-live data migrations — these need HDL's volume and automation capabilities
- Large-scale recurring integrations — HDL via OIC is the right approach for automated pipelines
- Cross-object loads with complex dependencies — HDL handles sequencing better for multi-object loads
Key technical detail: HSDL uses the same underlying HDL infrastructure. If HSDL loads fail, they appear in the same HDL monitoring screens where technical teams can investigate alongside regular HDL loads.
FBDI — File-Based Data Import
FBDI is Oracle's file-based import mechanism for ERP modules — Finance, Procurement, Order Management, and Supply Chain. It is the ERP equivalent of what HDL is to HCM.
What it can load:
- Suppliers and supplier sites
- Customers and customer accounts
- AP and AR invoices
- Purchase orders
- Journals and journal entries
- Fixed assets
- Inventory items and on-hand balances
How it works:
- Oracle provides Excel macro files (XLSM) for each business object — these are the official templates
- The XLSM macro generates the required CSV files in the correct structure
- CSV files are compressed into a ZIP archive and uploaded to UCM (Universal Content Management)
- An ESS job is triggered to import the file and validate the data
- Errors are reported in the ESS job output and must be corrected before resubmitting
Key technical detail: Some Oracle business objects can only be loaded through FBDI — there is no REST API equivalent for them. For example, certain invoice types and on-account credit memos can only be created through the AutoInvoice FBDI import process. Always verify whether a REST API alternative exists for the specific object before committing to FBDI as your approach.
What FBDI is not for: FBDI is ERP and SCM-specific. It cannot load HCM data such as workers, assignments, or employee records — those require HDL or HSDL.
REST APIs
REST APIs enable real-time communication between Oracle Fusion and external applications. Unlike HDL and FBDI, REST APIs are designed for individual transactional operations rather than bulk batch processing.
Where REST APIs are the right choice:
- Real-time or near-real-time integration requirements where data must be available immediately
- External applications (mobile apps, portals, third-party SaaS platforms) that need to interact with Fusion continuously
- Low to moderate volume operations — individual record creates, updates, and reads
- Event-driven architectures where a change in an external system should immediately trigger a Fusion update
Critical limits to know:
- Oracle recommends a maximum of 500 records per POST request — exceeding this causes timeouts or partial failures
- GET operations return a maximum of 500 records per call; pagination with
offsetandlimitparameters is required for larger result sets - Informal rate limits suggest roughly 5,000 API calls per hour per identity domain — sustainable for transactional workloads, not for bulk migrations
- Not all operations are supported on every resource — if GET works but PATCH doesn't, check whether the resource supports that method before building the integration
- The user or service account making API calls needs the correct job roles assigned in the Fusion Security Console — authentication alone is not sufficient
What REST APIs are not for: REST APIs should not be used for high-volume bulk data loads. For migrations involving thousands of records, HDL or FBDI will always be more appropriate — both for performance and for error visibility.
The Decision Framework
The two questions that determine the right method:
What module are you loading into?
- HCM data (workers, assignments, jobs, grades, element entries) → HDL or HSDL
- ERP data (invoices, suppliers, journals, assets) → FBDI
- Cross-module real-time operations → REST APIs
How much data, and how fast does it need to be available?
- High volume, batch acceptable → HDL (HCM) or FBDI (ERP)
- Low to medium volume, immediate → REST APIs
- Business user self-service updates, medium volume → HSDL (HCM only)
A simple pattern to remember:
- Real-time, low volume, any module → REST APIs
- Bulk, HCM, technical team → HDL
- Bulk, HCM, business users → HSDL
- Bulk, ERP or SCM → FBDI
Real Project Scenarios
Scenario 1: 12,000 Employees After an Acquisition
Requirement: Onboard all employees from the acquired company into Oracle Fusion HCM.
Best choice: HDL
Configuring multi-threading for a load of this size significantly reduces processing time. Loading in logical batches per business object (Workers first, then Assignments, then Element Entries) allows errors to be isolated and corrected without reloading the entire dataset. Using REST APIs for 12,000 employees would require thousands of individual calls, each with a 500-record maximum, making the process slower and harder to manage.
Scenario 2: Monthly Supplier Import From a Legacy System
Requirement: Every month, supplier records arrive from an external procurement platform and need to be loaded into Fusion.
Best choice: FBDI
Oracle provides predefined FBDI templates for supplier imports. The process is reliable for scheduled batch imports and handles the volume without the API call overhead that a REST-based approach would carry for this same volume.
Scenario 3: Real-Time New Hire from an External ATS
Requirement: When a candidate is hired in an external applicant tracking system, the employee record must be created in Oracle Fusion immediately.
Best choice: REST APIs (via OIC)
The business requirement is real-time — the employee record should be available in Fusion the moment the hiring action is completed externally. A REST API call via OIC meets this requirement directly. HDL would require waiting for a scheduled batch, which doesn't suit real-time onboarding workflows.
Scenario 4: Post Go-Live HR Address Updates
Requirement: HR business analysts need to update employee home addresses for 300 employees following an office relocation without involving the technical team.
Best choice: HSDL
HSDL gives HR analysts a spreadsheet interface with validation and familiar Excel tooling. The team doesn't need to know HDL file format requirements. The administrator configures the template once; the HR team reuses it independently. This is exactly the post go-live operational scenario HSDL is designed for.
Scenario 5: Initial ERP Data Migration at Go-Live
Requirement: Migrate historical supplier, customer, and invoice records from a legacy ERP system into Oracle Fusion Financials.
Best choice: FBDI
FBDI is built for this purpose — large ERP data migrations with Oracle-supported templates, UCM upload, and ESS job processing. Breaking the load into logical batches per business object type makes error management tractable, and the process integrates cleanly with the Oracle import framework.
Scenario 6: Employee Self-Service Address Update via Mobile App
Requirement: An employee updates their address through a company's self-service mobile application and the change should appear in Fusion immediately.
Best choice: REST APIs
A single-record update triggered by a user action on a mobile app is the definition of a REST API use case — low volume, real-time, event-driven.
Advantages and Limitations
HDL
Advantages:
- Purpose-built for HCM bulk loading — handles complex HCM object hierarchies
- Multi-threaded processing configurable per load
- MERGE instruction handles create and update in a single run without needing to know if the record exists
- Fully automatable via web services and OIC — no manual intervention required for recurring pipelines
- Source key identification enables reliable referencing across multiple loads and systems
- Binary attachments (images, documents) loadable in the same archive
- Two-phase validation provides clear error visibility before data reaches application tables
Limitations:
- HCM modules only — cannot load ERP or SCM data
- Requires technical knowledge to build and maintain
.datfiles - Not suitable for real-time requirements — batch process with processing time
- Load order must be respected across business objects to avoid reference errors
HSDL
Advantages:
- Excel-based interface accessible to business users — no technical file format knowledge needed
- Real-time on-screen validation reduces errors before submission
- Built on the same HDL infrastructure — reliable and consistent with the broader HCM data loading framework
- Configurable templates give administrators control over what fields are exposed and what validations apply
Limitations:
- HCM only — same module restriction as HDL
- Not suitable for very large volumes or automated recurring pipelines
- Errors from HSDL appear in HDL monitoring screens — technical team involvement may still be needed for complex failures
FBDI
Advantages:
- Oracle-provided templates reduce the risk of file format errors
- Handles large ERP data migrations reliably
- Integrates with Oracle's import framework (UCM + ESS jobs)
- Some business objects are only loadable via FBDI — no REST alternative available
Limitations:
- ERP and SCM modules only
- Not real-time — batch processing with no immediate feedback
- Requires UCM upload and ESS job execution, which adds steps compared to REST
- Excel XLSM macro must be used correctly to generate the CSV ZIP — formatting errors are a common source of failures
REST APIs
Advantages:
- Real-time response — changes are available in Fusion immediately
- Works across all modules — ERP, HCM, SCM, CX
- Easy integration with external applications and third-party SaaS platforms
- Supports CRUD operations and custom actions
- Pagination allows traversal of large result sets
Limitations:
- 500-record maximum per POST operation
- Not suitable for bulk migrations — volume, rate limits, and error visibility all become problems at scale
- Security setup required beyond just authentication — correct job roles must be assigned to the service account
- Not all operations are available on all resources — some objects require FBDI or SOAP alternatives
Common Interview Questions
When would you choose HDL over REST APIs for an HCM integration?
When the volume is too large for individual API calls, when you need to load complex HCM object hierarchies in a specific order, when you want multi-threading to control processing speed, or when you need a fully automated, schedulable pipeline. REST APIs are the right call when the business requirement is real-time and the volume per transaction is low.
Why is FBDI used instead of REST APIs for ERP data migration?
ERP data migrations involve large volumes that would require thousands of individual REST calls, each limited to 500 records, each with its own error handling. FBDI processes the data in bulk through Oracle's native import framework, handles validation and error reporting at scale, and some ERP objects have no REST API equivalent at all.
What is the difference between HDL and HSDL?
Both use the same underlying HDL infrastructure and processes. The difference is the interface and intended user. HDL is for technical integration specialists working with pipe-delimited flat files, typically in automated pipelines. HSDL is for business users working in Excel spreadsheets, typically for post go-live operational updates in smaller volumes.
Can REST APIs replace HDL or FBDI completely?
No. REST APIs are designed for real-time, low-volume transactional operations. For large data loads and migrations, HDL and FBDI will outperform REST on speed, error visibility, and reliability. The 500-record POST limit alone makes REST impractical for migrations involving tens of thousands of records.
What is the MERGE instruction in HDL and why is it recommended?
MERGE tells HDL to create the record if it doesn't already exist, or update it if it does — without requiring the developer to know in advance which state the record is in. This is the recommended instruction for most HDL loads because it handles both creates and updates in a single file without needing separate logic to check record existence first.
Best Practices
HDL:
- Use source keys (SourceSystemId + SourceSystemOwner) for all implementations — they're more reliable than user keys for updates and essential when the same system loads data across multiple runs
- Deliver one business object type per ZIP file to isolate failures and allow targeted resubmission
- Adjust thread count for large loads to improve processing speed
- Fix all Import phase errors before the Load phase begins
- Design loads to be idempotent — safe to rerun without creating duplicates
HSDL:
- Configure templates carefully — restrict visible columns to only what's needed to reduce user error
- Add appropriate field-level validations and help text in the template
- Use HSDL for smaller, business-user-driven updates; hand off to HDL for large volumes or automation
FBDI:
- Always use Oracle's provided XLSM macro to generate the ZIP file — manual CSV creation frequently introduces formatting errors
- Break large migrations into logical batches by business object
- Validate reference data (ledgers, business units, suppliers) exists in Fusion before importing dependent data
REST APIs:
- Never exceed 500 records per POST request
- Implement pagination for all GET operations that could return more than 500 results
- Verify the specific operation (GET, POST, PATCH, DELETE) is supported on the resource before building the integration
- Ensure the service account has the correct Fusion security roles — authentication is not the same as authorization
- Add retry logic with idempotency for any POST or PATCH operations to handle intermittent failures cleanly
Frequently Asked Questions
Which integration method is best for Oracle Fusion HCM? HDL for bulk technical loads and migrations. HSDL for business user-driven operational updates. REST APIs for real-time integrations triggered by external systems.
Is FBDI only used for ERP modules? FBDI is primarily designed for ERP data imports — financials, procurement, order management, and supply chain. HCM data uses HDL or HSDL.
Should I use REST APIs for a large data migration? No. The 500-record POST limit, API rate limits, and limited error visibility make REST APIs unsuitable for large migrations. Use HDL for HCM and FBDI for ERP.
What is the MERGE instruction in HDL? MERGE tells HDL to create the record if it doesn't exist, or update it if it does. It's the recommended instruction for most loads since it handles both scenarios without needing to know the record's current state.
Join the Discussion on Lanverse
- Share an HDL or FBDI issue that took you longer to debug than expected
- Read real Oracle Fusion Technical Consultant interview experiences
- Check Oracle Fusion Technical Consultant salary data by experience and city
Lanverse is India's Oracle-specialised career intelligence platform — real salary data, real interview experiences, and a community built for Oracle consultants. Visit lanverse.in