You call an Oracle Integration Cloud (OIC) REST endpoint to validate an invoice against Oracle Fusion — check the supplier, check the PO, check the receipt. The HTTP response comes back 200 OK. Your code sees 200, concludes the call succeeded, and moves the invoice forward.
Except the operation inside Fusion actually failed. The supplier lookup errored, the PO check threw, the validation never completed — and your AP automation just waved through an invoice on the strength of a status code that didn't mean what you assumed it meant.
This is one of the most important — and least obvious — conventions to handle when integrating with OIC. If you treat HTTP status as the source of truth for business outcomes, OIC will silently lie to you, and the failures will be the worst kind: the ones that look like successes.
Why OIC returns 200 on failure
OIC orchestrations sit between your client and the Oracle Fusion application. The HTTP 200 you receive reflects the success of the integration flow itself — the orchestration ran, reached the end, and returned a response. It does not necessarily reflect the success of the business operation the flow was carrying out.
So a flow can execute perfectly, encounter a downstream Fusion error, package that error into its response, and return it with a 200 — because from the orchestration's perspective, returning the error is the successful outcome. The real result is carried elsewhere:
- A custom response header, commonly something like
X-Status-Code, conveying the true outcome code. - A
statusfield in the response body — for example"status": "Error"— with an error code and message alongside it.
The HTTP layer says "200, all good." The header and body say "this actually failed." Both are true; they're just describing different things.
The bug this creates
If your client checks only the HTTP status code, the failure path is never taken. An error response with a 200 falls straight through the happy path. In an AP context that's dangerous:
- A validation that errored (didn't actually verify anything) gets read as valid.
- An invoice that should have been held for a supplier or PO problem proceeds toward payment.
- Nothing logs an error, because as far as the code is concerned, nothing went wrong.
This is precisely the class of silent failure that erodes trust in automation. The invoices that slip through aren't randomly wrong — they're systematically the ones where the validation itself broke.
Reading the response the right way
The fix is to treat the HTTP status code as necessary but not sufficient, and to inspect what OIC actually returned. In practice that means: after confirming the transport succeeded, check the custom status header and the body's status field, and only treat the call as a real success when all three agree.
// HTTP 200 alone is not "success" — inspect OIC's own signals
const xStatusCode = resp.headers['x-status-code'];
if (xStatusCode && xStatusCode !== '200') {
// OIC executed but the downstream operation failed
if (resp.data && resp.data.status === 'Error') {
return { status: 'Error', message: resp.data.errorMessage };
}
}
The rule is simple to state and easy to get wrong: always check the status field, not just the HTTP code. A response is only genuinely successful when the transport returned 200, the custom status header doesn't indicate an error, and the body's status field confirms success.
Surfacing real Fusion errors
Once you read the response correctly, you get something valuable: the actual reason Fusion rejected the operation. Those error messages are specific and actionable — things like an accounting date that falls in a closed period, an unrecognized unit of measure, an item or payment term that doesn't exist in Fusion, or a duplicate invoice number. Each one tells AP exactly what to fix.
That's the second half of doing this well. It isn't enough to detect that the call failed — you want to carry the real error back into your own workflow so a human sees "payment terms not valid in Oracle," not a generic "validation failed." The whole point of reading the header and body is to turn an opaque 200 into a meaningful, routable exception.
A robust OIC integration, in short
Handling OIC's convention well comes down to a few habits:
- Never equate HTTP 200 with business success — the status code reflects the orchestration, not the operation.
- Read the custom status header (e.g.
X-Status-Code) and the body'sstatusfield on every call. - Require all signals to agree before treating a response as successful.
- Propagate the real Fusion error into your workflow so exceptions are meaningful and actionable.
This is the same respect-the-platform's-contract thinking that keeps an integration durable across Fusion's quarterly updates — reading what Oracle actually tells you, the way Oracle tells you, rather than assuming the transport layer speaks for the application. It connects directly to the broader question of what a dedicated AP layer adds on top of Fusion's own capture: trustworthy validation is exactly the kind of operational depth that capture alone doesn't provide.
Where EZ Cloud fits
EZ Cloud reads OIC responses the way Oracle intends — checking the custom status header and the response body's status field, not just the HTTP code — so a failed validation is treated as a failure, held for review, and surfaced with the real Fusion error message attached. No invoice proceeds on the strength of a misread 200. That's the native ERP integration approach we take everywhere: respect the platform's own conventions so automation stays trustworthy, which is exactly what we built our Oracle EBS and Fusion integration to do.
If you've ever found an invoice that "passed validation" but clearly shouldn't have, an unread error behind a 200 is a prime suspect — and closing that gap is what turns OIC from a black box into a reliable validation layer.