Originally published on Towards AI.
When Oracle introduced the OpenAI Adapter in Oracle Integration Cloud (OIC), most of the examples I came across focused on text generation and chatbot-style interactions.
Naturally, I assumed that if I wanted to process files such as images, PDFs, or Word documents, I would probably need to build custom REST integrations and call the OpenAI APIs directly.
While exploring the adapter, I noticed a few operations related to file management. That got me curious.
Can the OpenAI Adapter upload files?
Can those files be processed later using a File ID?
Can we extract structured data from invoices, images, or PDF documents without building custom REST calls?
To answer these questions, I decided to build a small proof of concept.
The results were quite interesting.
Using only the native OpenAI Adapter, I was able to:
In this article, I’ll walk through the approach, the architecture, and a few practical use cases that I tested while building the POC.
By the end, you’ll have a reusable pattern that can be applied to invoice extraction, document processing, content analysis, and many other AI-powered integration scenarios.
While building the POC, I decided to separate the solution into two integrations.
The first integration is responsible for uploading a file to OpenAI and obtaining a File ID.
The second integration uses that File ID together with a prompt to process the document and return a structured response.
I found this approach cleaner because the uploaded file becomes a reusable asset. The same file can be analyzed multiple times using different prompts without uploading it again.
The first integration accepts a file and uploads it using the OpenAI Adapter’s Upload File operation.
Supported examples include:
The adapter returns a unique File ID similar to:
file-xxxxxxxxxxxxxxxx
This File ID can then be stored, logged, or passed to another integration for processing.
The second integration receives:
It then invokes the OpenAI Adapter using the Responses operation.
Depending on the type of document and the prompt provided, OpenAI can:
The response can be consumed directly within OIC and mapped to downstream systems.
The overall process looks like this:
Document
(Image/PDF/DOCX)
|
v
+------------------+
| Upload File |
| OpenAI Adapter |
+------------------+
|
v
File ID
|
v
+------------------+
| Responses API |
| OpenAI Adapter |
+------------------+
|
v
Structured Output
(JSON)
One thing I particularly liked about this pattern is that it relies entirely on the native OpenAI Adapter. There are no custom REST calls, no manual API payload construction, and no need to manage Base64-encoded content.
The first integration is responsible for uploading a document to OpenAI and obtaining a File ID that can be reused later.
In my case, I tested the following file types:
Start by creating a connection using the OpenAI Adapter.
Provide:
Once the connection is successfully tested, it can be used within your integration.
Create an App-Driven Orchestration.
2.1 Add Trigger Rest Adapter to Accept File as input with:
– Select the multipart attachment processing options
2.2 Add the OpenAI Adapter and select the following operation:
Upload File
This operation allows OIC to upload a file directly to OpenAI without invoking the REST API manually.
The Upload File operation expects two important pieces of information:
The purpose determines how the uploaded file will be used.
For image processing:
vision
For document processing (PDF, DOCX, TXT, etc.):
user_data
Map the incoming attachment or file reference to the adapter’s File element.
Example mapping:
RequestWrapper
├── Purpose
└── File
└── streamReference
The adapter handles the upload process and stores the file within OpenAI.
After activation, invoke the integration with a sample document.
If the upload succeeds, the response contains a File ID.
Example:
file-3UoRxBRyqV7pJRgPC4WSgi
This File ID becomes the bridge between the upload step and the document processing step.
While testing the Upload File operation, I ran into an issue that took a little time to troubleshoot.
Some uploads failed when the file name contained spaces or special characters.
For example:
WhatsApp Image 2026-06-05 at 7.25.23 PM.jpeg
After renaming the file to a simpler format without spaces or special characters, the upload completed successfully.
Example:
invoice_20260605.jpeg
If you encounter unexpected upload failures, one of the first things to check is the file name.
Although this may vary depending on the adapter version and environment, using clean file names is a good practice and helped avoid issues during testing.
Initially, I assumed I would need to send Base64 content to OpenAI every time I wanted to analyze a document.
The File ID approach is much cleaner.
Once the document is uploaded:
This makes the pattern both efficient and easy to maintain.
At this stage, we have successfully uploaded a document and obtained a File ID.
The next step is where things become interesting: using that File ID to extract meaningful information from the document.
“This was the point where I realized the adapter was capable of much more than chat-based interactions. The File ID effectively turns the uploaded document into a reusable asset that can be processed multiple times.”
Now that the document has been uploaded and we have a File ID, the next step is to ask OpenAI to process the file.
This is where the Responses operation comes into play.
The Responses API allows us to provide:
and receive a structured response.
Create a second integration.
This integration accepts:
FileId — Contains the OpenAI File ID returned by the Upload File integration.
FileType — Determines the type of file being processed. For images, I passed input_image, while for PDFs and Word documents, I passed input_file.
instruction — Contains the prompt or instructions that should be sent to the model.
Add the OpenAI Adapter and select:
Responses
The request consists of two content elements:
The first content item contains the instructions we want the model to follow.
Example:
Extract invoice information from the attached document.
Return valid JSON only.
Include:
- Invoice Number
- Date
- Items
- Tax
- Total Amount
In the mapper:
Type = input_text
Text = <your prompt>
The second content item references the uploaded file.
For image files:
Type = input_image
File Id = file-xxxxxxxx
For PDF and Word documents:
Type = input_file
File Id = file-xxxxxxxx
The File ID comes from the Upload File integration we created earlier.
At runtime, OpenAI retrieves the uploaded file and processes it together with the prompt.
Inside the Responses request, I configured the following mappings:
gpt-4.1userinput_textinstructionFileTypeFileIdThis design allowed me to use the same integration for multiple scenarios simply by changing the values passed at runtime.
For example, when processing a restaurant invoice image, I passed:
input_imageFor a PDF document, I only changed the FileType and instruction:
input_fileThe integration logic remained exactly the same.
For my testing, I used GPT-4.1.
Recommended settings:
Temperature = 0
When extracting structured information, deterministic responses are generally easier to consume downstream.
After activation, invoke the integration using:
The model analyzes the file and returns a response.
A typical response might look like:
{
"Result" : "```json\n{\n \"Invoice Number\": \"123982857\",\n \"Date\": \"23/04/2022\",\n \"Items\": [\n {\"Item Name\": \"شاورما دجاج عربية عصملية\", \"Qty\": 1, \"Total\": 8.000},\n {\"Item Name\": \"حمص\", \"Qty\": 2, \"Total\": 4.000},\n {\"Item Name\": \"فتوش\", \"Qty\": 1, \"Total\": 3.000},\n {\"Item Name\": \"تبولة\", \"Qty\": 1, \"Total\": 2.500},\n {\"Item Name\": \"بطاطا مقلية\", \"Qty\": 1, \"Total\": 2.000},\n {\"Item Name\": \"خبز صاج\", \"Qty\": 2, \"Total\": 1.000},\n {\"Item Name\": \"شاورما لحم عربية\", \"Qty\": 1, \"Total\": 8.000},\n {\"Item Name\": \"كولا زجاج\", \"Qty\": 2, \"Total\": 4.000},\n {\"Item Name\": \"لبن\", \"Qty\": 2, \"Total\": 4.000},\n {\"Item Name\": \"مية 250 مل\", \"Qty\": 2, \"Total\": 2.000}\n ],\n \"Tax\": 2.420,\n \"Total Amount\": 46.570\n}\n```"
}
What impressed me most was that the model not only extracted the invoice totals, but also correctly identified Arabic item names, quantities, and line totals, and returned them in a clean JSON structure.
Within OIC, this response can be parsed and then can be mapped directly to downstream applications or business processes.
To validate the solution, I started with a restaurant invoice written in Arabic.
The objective was simple:
Rather than returning a textual description of the invoice, the model was instructed to generate JSON containing:
The result was surprisingly accurate.
The model successfully identified:
This demonstrates how the OpenAI Adapter can be used as a lightweight document extraction service directly within Oracle Integration Cloud.
Potential use cases include:
For organizations already using OIC, this pattern can significantly reduce manual data entry and simplify document-driven workflows.
After validating the invoice extraction scenario, I wanted to see how the adapter would perform with larger documents.
For this test, I used Persian and Arabic PDF documents containing multiple pages of text.
The goal was different from the invoice use case.
Instead of extracting business fields, I wanted to:
The prompt instructed the model to return page-wise JSON.
A simplified response structure looked like this:
{
"pages": [
{
"page_number": 1,
"paragraphs": [
"...",
"..."
]
}
]
}
The results were encouraging.
The model was able to:
This opens up interesting possibilities for:
One important observation is that document understanding and transcription accuracy are two different goals.
For scenarios where verbatim OCR accuracy is critical, Oracle Document Understanding may still be a valuable companion service. However, for document analysis and content structuring, the OpenAI Adapter performed remarkably well.
Result field.The complete Oracle Integration Cloud package (.car), sample prompts, and supporting assets used in this article are available on GitHub.
GitHub Repository:
https://github.com/sarfarazmerchant/oic-openai-adapter-file-processing.git
Feel free to download the package, import it into your OIC environment, and adapt it to your own document-processing use cases.
This proof of concept demonstrated that the OpenAI Adapter in Oracle Integration Cloud can do much more than chat interactions. By combining the Upload File and Responses operations, I was able to process images, PDFs, and Word documents, and transform them into structured JSON ready for downstream integrations.
The pattern is simple:
Upload File
↓
Get File ID
↓
Process with Responses API
↓
Receive Structured Data
For me, this was a practical introduction to AI-powered document processing in OIC, and I hope it helps other integration developers explore similar use cases.
Have you explored the OpenAI Adapter in OIC? I’d love to hear about your use cases and experiences.
Published via Towards AI
15 engineers. 100,000+ students. Towards AI Academy teaches what actually survives production.
Start free — no commitment:
→ 6-Day Agentic AI Engineering Email Guide — one practical lesson per day
→ Agents Architecture Cheatsheet — 3 years of architecture decisions in 6 pages
Our courses:
→ AI Engineering Certification — 90+ lessons from project selection to deployed product. The most comprehensive practical LLM course out there.
→ Agent Engineering Course — Hands on with production agent architectures, memory, routing, and eval frameworks — built from real enterprise engagements.
→ AI for Work — Understand, evaluate, and apply AI for complex work tasks.
Note: Article content contains the views of the contributing authors and not Towards AI.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。