7 curated examples - cart return and setup request - illustrating both clean configurations (OCI 4.0, OCI 5.0 attachments) and classic traps (PRICEUNIT x1000, [0] indexing, ~Target=_self, etc.). Copy, download, or test directly in the validator.
Test data only - never use in production.
All values (VENDOR, VENDORMAT, product codes, HOOK_URL, credentials) are fictional. Use these examples as a reference structure then replace each value with your own.
Setup request
OCI session opening URL - built by the buyer (SAP SRM, S/4HANA, etc.) to enter the supplier catalogue. Parameters USERNAME, PASSWORD, HOOK_URL, ~OkCode, ~Target, etc.
The recommended configuration for an OCI call to a supplier catalogue in production.
Setup RequestClean
OCI session opening URL following best practices: HTTPS for the tunnel, distinct USERNAME and PASSWORD, absolute HTTPS HOOK_URL, ~OkCode=ADDI (add to current SAP shopping cart), ~Target=_top (escapes all iframes so the cart return bubbles up to the SRM window level), ~Caller=CTLG, and LANGU=FR to serve the catalogue in French. This is exactly the pattern a SAP SRM buyer configures on the supplier side in the OCI connection table.
Setup request with warnings - frame trap, HTTP, PASSWORD in query
Three common bad practices that silently break punchout in production.
Setup RequestWarnings
Three traps to avoid, all present in this URL: (1) HOOK_URL over HTTP - silently blocked by Chrome as mixed-content from an HTTPS catalogue. (2) ~Target=_self traps the return form in the current frame (classic SRM-behind-reverse-proxy case: HOOK_URL never fires). (3) PASSWORD passed in the GET query string instead of a POST form-urlencoded body - the password ends up in every reverse proxy log and browser history. The Gatebold validator raises a warning on each point without blocking validation.
application/x-www-form-urlencoded body POSTed by the supplier catalogue to the buyer's HOOK_URL, containing the NEW_ITEM-*[i] lines.
Minimal cart return - 1 line, required fields only
The smallest valid OCI cart return that passes with no error or warning.
Cart ReturnOCI 4.0Minimal
The smallest technically valid OCI 4.0 cart return: a single line with the five required fields (DESCRIPTION, QUANTITY, UNIT, PRICE, CURRENCY). No VENDOR, no MATGROUP, no DELIVERYDATE. Useful to start an integration from scratch and verify that the HOOK_URL tunnel works before enriching the mapping. Note: without MATGROUP (UNSPSC), many SAP buyers will auto-recategorise the line into a default group - it is deliberately omitted here to show the strict minimum.
Three varied lines with VENDOR, UNSPSC MATGROUP, DELIVERYDATE and a service line.
Cart ReturnOCI 4.0Complet
A realistic B2B catalogue return over OCI 4.0. Three lines: Cat6a cable (network hardware, UNSPSC 43222600), an IEC power cord (UNSPSC 39121600), and a service line (NEW_ITEM-SERVICE=X, unit HUR = hour). Each line carries its vendor reference (VENDOR + VENDORMAT), its UNSPSC code (MATGROUP) and the first line pushes a requested delivery date. This is the richness level a SAP buyer expects in production - the technical minimum is never enough beyond a POC.
Demonstrates the #1 source of pricing errors in OCI integration: PRICEUNIT misinterpreted by the buyer.
Cart ReturnOCI 4.0Piège
The supplier sends a unit price of 12.50 EUR... for 1000 units (PRICEUNIT=1000) on screws. The actual per-piece price is 0.0125 EUR. If the SAP buyer does not map PRICEUNIT in MM-PUR, they will bill 12.50 EUR per piece - a factor-1000 error. This is the most expensive and most silent bug in the OCI protocol: no validation error, no encoding warning, just a cart that lands in SAP with an astronomical amount. The Gatebold validator computes the effective price and explicitly flags this line.
A deliberately broken cart to see what the validator actually catches.
Cart ReturnDémo erreurs
Four lines, four error categories: (1) A line on the forbidden index [0] per OCI 4.0 spec, plus a non-existent currency (XXX). (2) A line [2] where the required PRICE field is missing. (3) A line [3] with an invalid delivery date (2026-13-45). (4) Indices [0], [2], [3] non-contiguous, the validator will also flag the index gap. This is the perfect payload to understand which checks the validator runs before you send your real production cart return.
OCI 5.0 - attachments and external product references
A line enriched with ATTACHMENT, EXT_PRODUCT_ID (GTIN) and EXT_CATEGORY_ID (UNSPSC), specific to OCI 5.0.
Cart ReturnOCI 5.0
Demonstration of fields introduced by OCI 5.0: NEW_ITEM-ATTACHMENT (URL of a datasheet PDF), NEW_ITEM-ATTACHMENT_TITLE + PURPOSE, NEW_ITEM-EXT_PRODUCT_ID (GTIN/EAN code), NEW_ITEM-EXT_SCHEMA_TYPE (GTIN here), and NEW_ITEM-EXT_CATEGORY_ID/EXT_CATEGORY to push an external classification on top of MATGROUP. The validator recognises these fields and tags them as OCI 5.0 in the report. In practice, few SAP buyers will accept these fields without specific configuration - start in OCI 4.0 and negotiate the addition with the buyer.
UNSPSC Codes - the product/service referential for the NEW_ITEM-MATGROUP field.
Frequently asked questions
What are these examples for?
Each example is a realistic OCI payload ready to paste into the validator or to use as a starting point on the supplier side. Some illustrate clean configurations, others are deliberately broken to demonstrate classic errors (misread PRICEUNIT, forbidden [0] index, ~Target=_self, Latin-1 encoding, etc.) that the Gatebold validator detects.
Can I use these examples in production?
No, never directly. Values are fictional (VENDOR=ACME01, realistic UNSPSC codes paired with demo products, etc.). Use them as a reference structure and replace each value with the ones from your own catalogue and buyer.
How does the "Test in the validator" button work?
The button stores the payload in your browser's sessionStorage (key 'gatebold-oci-prefill') then redirects you to the OCI validator, which detects the prefill on load and automatically inserts the payload into the input. The data never leaves your browser.
What is the difference between cart return and setup request?
The setup request is the session opening URL that the buyer (ERP/SRM) opens to enter the supplier catalogue. The cart return is the POST body that the supplier catalogue sends back to HOOK_URL once the buyer has validated their cart. The two flows together make a complete OCI PunchOut.
