The OIC replacement that lives in Git
Describe the integration in plain English. The AI lays out the flow — triggers, Oracle calls, transformations. Review the diagram, ship it. No sealed zips. No drag-and-drop lock-in. No per-pod copies that drift.
Built for Oracle Fusion teams that want their middleware in Git.
The OIC problem
mod="JYr8e3gWYjo8aWnq1GmxXg=="
// server-side hash check —
// edit a single byte and OIC rejects itOracle signs every .iar with a cryptographic hash. Change anything outside the Designer — even a typo — and the import fails with ICS-20099. You cannot version them in Git. You cannot diff them in a PR. You cannot let an AI look at them.
# What you want:
git diff flow.yaml
# What OIC gives you:
"Open in Oracle Integration Designer"Every change is a click in a proprietary web UI. No diffs. No code review. No PRs. You promote by exporting a zip and re-importing it into the next pod, hoping the connections were configured the same way.
dev1: draft-invoice-burst v2.3 (3 changes)
prod: draft-invoice-burst v1.7 (stale)
# You find out at 3am when prod fails
# on a bug that was fixed in dev1 last monthOIC stores a separate copy of every integration on every pod. There is no canonical version. Promotion means export-import-promote with no guarantee the target matches the source. Drift is the default. Rollback means finding the right old .iar on someone's laptop.
ICS-20099. ICS-10994. Designer-only edits. Per-pod copies.
You know the pain. We built the answer.
01 / build
Describe the integration in plain English. The AI assistant proposes the flow: triggers, Oracle calls, transformations, fan-outs. You see a clean visual diagram. Approve it, or refine it in chat — the result is reviewable, governable code under the hood.
Drafted a flow with four steps:
Diagram on the right. Looks good?
02 / deploy
Write the flow once; deploy it to dev, test, and production with a single config update. Approval workflows per environment. Atomic version pins. Instant rollback. No re-importing archives. No copies that silently disagree.
03 / govern
Every flow change, deployment, approval, and execution is logged to an immutable audit record. Every step capture is searchable. When something fails, the AI assistant explains why in plain English — and proposes the fix.
Three plans. No usage gotchas. Multi-entity and volume discounts on request.
For Oracle Fusion teams running their first integrations on ERPHive.
Production-grade. Approval workflows, dedicated support, single-tenant isolation.
Multi-entity programmes, regulated industries, on-premise or sovereign cloud.
All plans billed annually. Volume and multi-entity discounts on request.
Both run Oracle Fusion integrations. The operating model is fundamentally different.
| Oracle Integration Cloud | ERPHive | |
|---|---|---|
| Build experience | Drag-and-drop in a sealed editor | Visual + AI assistant + code if you want it |
| Promotion | Export and re-import per environment | One-click promote, instant rollback |
| Versioning | Each environment holds its own copy | One immutable history across all environments |
| Audit | Activity Stream | Immutable, append-only, queryable |
| Failure analysis | Open a Sev-2 ticket | AI assistant explains and proposes the fix |
| Approval workflows | Manual | Per-environment policies, configurable |
| Migration from OIC | — | Drop the .iar — flow is rebuilt for you |
Migrate your existing OIC integrations through erphive.com/migrate.
.iar at /migrate and ERPHive rebuilds it as a managed flow. Best-effort by design — anything that doesn't translate cleanly is surfaced as a gap for the AI assistant or your engineer to resolve.