IATA ONE Record · API 2.2.0 · developer portal

ConnectedCargo — the ONE Record Developer Portal

One path for a prime-contracted actor — forwarder, GHA, carrier, customs, shipper, IT vendor — to discover, evaluate, onboard, and integrate with CC's ONE Record adapter. Four layers, each a real surface on the node; two ways to integrate; one neutral control plane.

Layer 1Discover
GET /onerecord
See every capability surface — reads, events, subscriptions, delegations, data products — in one index.
The front door. Links out to the OpenAPI, the studio, the sandbox, and the JSON-LD @context.
Layer 2Evaluate
GET /onerecord/studio/onerecord/docs↗new/openapi.json
Experiment against your own base URL, tenant and token. Two doors over one curated surface: the studio runs guided flows — dereference an LO, subscribe & watch a notification arrive, publish a data product, run a governed write — with a live notification inbox; /onerecord/docs is a real interactive Swagger console with per-endpoint try-it-out.
Config-aware studio + a genuine Swagger console (self-hosted, no CDN), not a static page. Evaluate the adapter without touching your production systems. Open the live console → /onerecord/docs↗ (served first-party through both fronts; becomes the public URL at P6 go-live).
Layer 3Onboard
POST /onerecord/partners
Register your OAuth2 client and be granted the tenant Access Delegations you're entitled to — reads flip from 403 to 200. One call provisions the CC-side of the relationship.
The Keycloak client + secret is issued in your IdP; this records the entitlement.
Layer 4Integrate
systems registry
Pick how you integrate — build an app, connect your server, or both — and manage it in CC's neutral control plane: entitlements, tokens, capabilities, in one catalogue.
Same registry whether you speak ONE Record natively or through CC's gateway.

Two ways to integrate

A · build on CC's API
Custom app on CC's API
  • Authenticate as an OAuth2 client (client_credentials)
  • Dereference Logistics Objects · read events · audit trail
  • Subscribe → receive api:Notification callbacks
  • Consume CC's intelligence data products (UNIE·EIE·PRIME·e-UCR·VRC)
  • Write — POST/PATCH · Action Requests (ownership-approved)
Your app calls CC. Prototyped and evaluated in the studio first.
B · connect your server
Your ONE Record server
  • Register your (or your CMS's) ONE Record server as a source
  • CC consumes it — dereference + subscription-follow → NORM-1
  • Federation: link, don't duplicate — CC-owned LOs are never overwritten
  • CC enriches with intelligence the bare server can't produce
CC rides your server. How CC sits above the CMS-vendor hubs, vendor-neutral.
Systems registry — the neutral control planeone catalogue · entitlements · tokens · capabilities
The ONE Record gateway
standards-onerecord · CC's own provider surface (provide · ingest · subscribe · data products)
Consumed partner / CMS servers
CHAMP 1Neo-Connect · IBS iCargo · partner 1R servers — federated inbound (mode B)