Oracle Fusion REST API: Why You Can't DELETE a Record (and What to Do Instead)

A recurring question on Cloud Customer Connect: “Is there any REST API/Webservice available to delete or inactivate account sites in Oracle Fusion?” Oracle’s own support documentation is just as blunt about the person side — Doc ID 2075369.1, “Deletion of Person Records in Fusion,” states plainly that a complete person delete isn’t available, because the person object is an integral part of the application with references from other products, including Taleo. Add a support KB literally titled “Why has not Delete Functionality Been Consistent in Individual Record Deleted and Mass Additions Deleted?” and you have a genuine, recurring pattern: DELETE in the Oracle Fusion REST API is far less predictable than GET/POST/PATCH.

This post covers the three ways a DELETE call actually resolves, with catalog-verified real examples, and what to do when it isn’t available.

Outcome 1: the resource doesn’t support DELETE at all

Not every REST resource exposes a DELETE operation. Workers is the clearest example — the /workers resource’s supported operations are GET /workers, GET /workers/{id}, PATCH /workers/{id}, and POST /workers. There is no DELETE /workers/{id} in the catalog at all. Call it anyway and you’ll get a 404 Not Found or 405 Method Not Allowed depending on the framework version, not a business error — the method itself isn’t wired up for that resource.

This isn’t an oversight. It matches Oracle’s own stated position in Doc ID 2075369.1: person records can’t be deleted because too much of the application (and integrations like Taleo) hold references to them. If your integration needs to “remove” a worker, you’re not looking for DELETE — you’re looking at the worker termination endpoint covered in our Workers guide, which ends a work relationship without destroying the record.

Outcome 2: DELETE exists, but a business rule blocks it

Some resources do support DELETE. Two catalog-verified examples: absences (DELETE /absences/{id}) and invoices (DELETE /invoices/{id}). But the method being wired up doesn’t mean every record is deletable — the underlying business object still enforces its own rules, the same way PATCH with a null value can be silently rejected by validation rather than the REST layer.

For invoices specifically, a posted or already-paid invoice will reject a DELETE with a 400 Bad Request and a business-validation message rather than a generic HTTP error — Oracle’s own support knowledge base is full of module-specific variants of this (“You cannot delete this record because it is already in use,” “…because it is the first date-effective record”). The message tells you why, but the fix is functional (reverse or void the transaction through the proper business process), not a different REST call.

Outcome 3: it actually works

When the resource supports DELETE and no business rule blocks it — for example, withdrawing an absence request that hasn’t been approved yet — the call succeeds and returns 204 No Content. This is the case most integrators expect by default, which is exactly why outcomes 1 and 2 catch people off guard: DELETE behaves like a normal REST verb right up until it doesn’t.

Diagnostic table

Response	What it means	What to do
404 Not Found / 405 Method Not Allowed on the base resource	DELETE isn’t a supported operation for this resource at all	Check the resource’s supported operations (see below) — look for a status/lifecycle action instead (terminate, cancel, withdraw, inactivate)
400 Bad Request with a business-validation message	DELETE is supported, but this specific record fails a business rule (already posted, in use, referenced elsewhere)	Read the message — it names the blocking condition. Reverse/void/unlink through the proper business action first
204 No Content	Delete succeeded	—

Checking whether DELETE is supported before you call it

The most reliable way to know in advance is the resource’s /describe endpoint — its metadata lists which HTTP methods a resource actually supports, so you can confirm DELETE is present before writing integration code around it, rather than discovering a 405 in production.

OPAL bundles this operations metadata for 184 of the most-used Oracle Fusion Cloud REST endpoints locally — every resource’s supported methods (GET/POST/PATCH/DELETE), q fields, finders, and child resources are searchable offline, so you can check whether a resource even has a DELETE operation before you touch a live instance.

---

This post is part of our complete Oracle Fusion API guide — base URLs, authentication, q filters, finders, and common errors in one place.