OCI (Open Catalog Interface)
OCI (Open Catalog Interface) is SAP's protocol for PunchOut catalog sessions, connecting a buyer's SAP-based procurement system to a supplier's hosted catalog over plain HTTP. Instead of exchanging XML documents like cXML, an OCI session opens a catalog with session details passed as URL parameters, and the buyer's cart is returned as HTTP-posted name-value pairs. It covers the shopping and cart-return steps only — order and invoice automation aren't part of the standard — and its adoption concentrates around SAP SRM, S/4HANA sourcing, and Ariba deployments, more heavily in Europe than North America.
How an OCI session works
A buyer's SAP-based procurement system opens a catalog session with an HTTP GET or POST call to the supplier's site, carrying session identifiers and a return URL as parameters rather than as a signed XML document. The buyer shops the hosted catalog directly. When the cart is complete, the supplier's site posts it back to the return URL as HTML form fields — plain name-value pairs like NEW_ITEM-1.DESCRIPTION, NEW_ITEM-1.QUANTITY, NEW_ITEM-1.UNIT, and NEW_ITEM-1.PRICE — which the buyer's system parses back into a requisition line.
OCI vs. cXML
Both are PunchOut protocols solving the same problem, but they differ in origin, transport, and how much of the order lifecycle they cover.
| OCI | cXML | |
|---|---|---|
| Origin | SAP | Ariba |
| Transport | URL parameters and HTTP-posted name-value pairs | Structured XML documents |
| Covers | Catalog session and cart return | Session, cart return, and order/invoice documents |
| Common on | SAP SRM, S/4HANA, some SAP Ariba flows | SAP Ariba, Coupa, Jaggaer |
cXML's PunchOutOrderMessage and OrderRequest documents carry the transaction further than OCI's cart handoff does, which is why cXML remains the more widely adopted protocol across North American procurement platforms even where SAP is the buyer's ERP.
Versions
OCI 4.0, released alongside SAP SRM 4.0 in the mid-2000s, is the version most integrations still target. OCI 5.0 added JSON as an alternative to the original name-value-pair format, though HTTP POST with name-value pairs remains the more commonly implemented path for supplier catalogs today.
What OCI demands of your catalog data
The attribute burden is the same one PunchOut catalogs carry generally: every line the buyer's system parses needs a valid unit of measure, a price expressed per that unit, and a stable part ID that won't drift out from under a later reorder. OCI's simpler transport doesn't relax that requirement — it just means there's no structured document format catching a malformed field before it reaches the buyer's cart.
Frequently asked questions
Is OCI the same as cXML?
No. Both are PunchOut protocols that let a buyer shop a supplier's hosted catalog from inside their procurement system, but OCI (SAP's standard) transmits the cart as HTTP-posted name-value pairs, while cXML (Ariba's standard) uses structured XML documents and covers more of the order lifecycle, including order and invoice documents.
Does OCI support purchase orders and invoices?
Not natively. OCI covers the catalog session and cart-return steps. Order confirmation and invoicing typically happen through a separate channel, such as EDI, layered alongside the OCI PunchOut integration.
Which procurement systems use OCI?
OCI is native to SAP's own procurement stack — SAP SRM and S/4HANA sourcing — and is also supported by SAP Ariba alongside its own cXML. Adoption outside SAP-centric environments is limited; most non-SAP procurement platforms in North America default to cXML.
Do I need to support both OCI and cXML?
Depends on your buyer mix. A supplier selling primarily to non-SAP procurement platforms (Coupa, Jaggaer, most Ariba deployments) can usually get by on cXML alone. One with a meaningful base of SAP SRM or S/4HANA buyers, especially in Europe, will need OCI support as well.