What the OIC REST API actually covers (and what it doesn't)

The OIC 3 REST API is genuinely useful for the lifecycle work it covers. It is also surprising in what it leaves out. Here's the actual surface area, verified against the OIC 3 docs and tested against production OIC instances.

Lifecycle — fully scriptable

GET    /integrations                      list integrations
GET    /integrations/{id}|{code}|{code}|{ver}
POST   /integrations/{id}/activate         activate
POST   /integrations/{id}/deactivate
DELETE /integrations/{id}
POST   /integrations/{id}/clone
POST   /integrations/import                import an IAR
PUT    /integrations/archive               replace by upload
GET    /integrations/{id}/archive          export the IAR

These endpoints are stable and well-documented. Most teams that build CI for OIC focus here — schedule nightly exports for backup, scripted promotion across pods, automated activation after a ticket closes.

Connections — usable, not great

GET    /connections
POST   /connections                        create
PUT    /connections/{id}                   update (creds, URL)
POST   /connections/{id}/test              test the connection
GET    /connections/{id}/health            current state

Updating credentials and URLs at the connection level is fully supported. This is the single most scriptable surface in OIC and the right place to land per-environment configuration. ERPHive's connection_bindings table is modelled on the same separation.

Lookups — surprisingly scriptable

GET    /lookups
POST   /lookups                            create with values
PUT    /lookups/{name}                     full table replacement
DELETE /lookups/{name}

The shortest path to "edit-without-touching-the-IAR" is to push parameterisable logic into a lookup. A flow that looks up "ledger ID for business unit X" against a lookup table can be re-tuned by hitting PUT /lookups/{name} — no Designer round-trip, no IAR re-import.

Libraries — for transforms expressible as JS

GET    /libraries
POST   /libraries                          create
POST   /libraries/{id}/archive             update JS code
DELETE /libraries/{id}

OIC libraries are JS modules deployable via REST. Transforms that you'd otherwise express as XSL can move to a library and become hot-replaceable. This is how to insulate yourself from the IAR-rebuild treadmill for the parts of the flow that change frequently.

Schedules and certificates

GET/POST/PUT/DELETE  /integrations/{id}/schedule
GET/POST/DELETE      /certificates

Both are first-class REST resources. Cron expressions edit cleanly via PUT; certificates upload/rotate via POST + DELETE. No editor-only state.

What is NOT exposed

The honest gap, and the reason teams hit walls when they try to script OIC like a normal CI/CD target:

• The flow's internal graph. No PATCH on processors, transformers, applications, or orchestration shape. The Designer is the only producer of valid integration internals.
• XSL transforms inside an integration. No endpoint to update req_*.xsl or res_*.xsl in place. Mappings change requires a re-export.
• WSDLs and JCA descriptors attached to applications. Same story — read-only via the API.
• The mod hash recomputation. Server-side only; not exposed as a separate endpoint.
• Per-step run logs at structured granularity.Activity Stream returns text; you can't query "all step traces where step_id = transformer_24".

What this means in practice

The OIC REST API is sufficient for "deploy the IAR my Designer produced" and insufficient for "build my IAR programmatically." This is by design — Oracle wants the Designer to be the only producer.

For teams whose authoring workflow is increasingly AI-assisted or PR-reviewed, this is the gap that drives the move to file-based platforms. ERPHive exists in that gap: flow internals are plain text, every change is a Git diff, and the runtime executes the text directly without sealed-archive intermediation.