File-based delivery
Render a versioned file format and inspect its delivery result.
Some targets ingest files rather than individual JSON records. DataMaker separates the file template, the rendered artifact and the load result.
Prepare the file
Choose a supported file template for the target resource and release. Review column order, required values, encodings, control records and packaging rules. Render a small dataset and inspect the artifact before submitting it.
The API exposes file-template resources, POST /file-renders and POST /file-loads. Use the deployed API reference for the required template, dataset and target configuration. Do not treat an arbitrary CSV as interchangeable with a vendor-specific import format.
Submit and follow through
A rendered file is not a delivered dataset. Submit through the configured delivery workflow, retain the returned run identifiers and inspect polling results and vendor result artifacts.
POST /file-loads starts a data job and inherits everything that means: the same statuses, the same progress counters, the same cancel and resume, and its own approval before the job is created. It runs as render, package, upload and submit, checkpointing the stage it reached, and then hands off to a poll job that waits for the target to finish and reads the result artifact back - which is where accepted rows become key-map entries and rejected rows become quarantine.
For Oracle Fusion, supported FBDI/HDL workflows can package, upload and submit files and follow the ESS request. Review accepted rows, rejected rows and the resulting key mappings. A successful upload does not establish successful business import.
Keep rejected-data artifacts restricted because they can contain source values. Use reconciliation to record the final outcome and remaining exceptions.