Oracle Fusion REST API Error Code Reference: 400, 401, 403, 404, 412, 429, 500

Oracle doesn’t publish one list of what its REST API error codes mean. Each module documents its own status codes separately — Procurement’s Status_Codes.html isn’t Project Management’s, isn’t Risk Management’s — so you end up stitching codes together from memory, forum threads, and trial and error. This site already has a deep-dive guide for each of the seven codes you’ll actually hit in practice. This page is the index: one table, every code, the one-line cause, and the guide with the full fix.

The error codes

Code	Meaning	Most common cause	Full guide
400 Bad Request	Malformed request	Bad q syntax, missing required POST fields, wrong REST-Framework-Version, a DFF context/segment mismatch	400 Bad Request guide
401 Unauthorized	Fusion doesn’t know who you are	Wrong password, an expired OAuth access token, clock skew on iat/exp, a malformed Authorization header	Authentication guide (401 vs 403 table) · OAuth token refresh guide (invalid_grant, token expiry mid-integration)
403 Forbidden	Fusion knows exactly who you are and says no	Missing job/duty role for that resource and method, or a data role that doesn’t cover the record’s business unit/legal entity — works fine in the Fusion UI, fails over REST	Authentication guide
404 Not Found	Resource or record doesn’t exist at that path	Missing version segment, a deprecated resource name, a wrong composite-key path — or, on a few resources, an authorization failure that returns 404 instead of 403	404 Not Found guide
412 Precondition Failed	Your If-Match ETag is stale	Someone else updated the record between your GET and your PATCH	ETag and If-Match guide
429 Too Many Requests	Identity-domain rate limit hit	Too many calls in the window for your identity domain, usually from a tight polling loop with no backoff	Rate limits guide
500 Internal Server Error	Something failed server-side	A transient platform failure (retry) vs. an endpoint-specific bug (won’t retry away) — the guide below covers telling them apart	500 Internal Server Error guide

401 vs. 403 vs. 404 — the one mix-up worth memorizing

These three get confused constantly because they can all look like “it’s just not working”:

• 401 means Fusion doesn’t know who you are yet — bad credentials or an expired token.
• 403 means Fusion knows exactly who you are and is deliberately refusing — almost always a missing job/duty role, or a data role that doesn’t cover that business unit or legal entity. If a call works in the Fusion UI but 403s over REST with the same user, this is it, not an authentication problem.
• 404 on a real, correctly-spelled endpoint is sometimes authorization in disguise — a few resources return 404 rather than 403 when the calling user has no access, so a 404 doesn’t always mean “check your URL.”

See the authentication guide’s full 401-vs-403 table for the complete breakdown with real Cloud Customer Connect thread examples.

First thing to check on any error

Before chasing the specific code, confirm what shape you actually got. Oracle’s error payload itself depends on your REST-Framework-Version — pre-v4 you get a plain error string, v4 and later gives you a structured object with o:errorCode, o:errorPath, and o:errorDetails you can branch on programmatically. See the framework versions guide if your error-handling code is still parsing a raw string.

---

This page indexes the error-code coverage across this site. For the base URLs, authentication, q filters, and finders that prevent most of these errors in the first place, see the Oracle Fusion API guide.