CMA CGM Relaunches Its API Developer Portal

What's changing and when

CMA CGM is relaunching its developer portal this week. The current banner on api-portal.cma-cgm.com states that a new version of the API Portal will be available at the end of October 2026, featuring a new interface design, improved navigation, and enhanced functionality for a better developer experience. If you have anything integrated against this CMA CGM API portal, credentials, bookmarked docs, saved changelog links, this is the week to pay attention.

To be precise about scope: this is a portal relaunch, not (yet) a wholesale endpoint rewrite. The interface, navigation and catalog structure change. But portal relaunches at ocean carriers have a habit of coinciding with catalog restructuring, and CMA CGM's own product roadmap shows several API changes landing in the same quarter, which makes this a reasonable moment to re-test rather than assume nothing moved underneath you.

Why this matters even if you think of yourself as a parcel shipper

If your integration work has mostly been DHL, DPD, GLS, FedEx, UPS and the odd regional post, ocean carrier APIs can feel like someone else's problem. They're not, for most mid-to-large European manufacturers and retailers that import components from Asia or ship finished goods out by container. CMA CGM alone covers a lot of ground: its API surface spans Track and Trace, Schedules, Booking Request, Quotation and Invoice, alongside a parallel EDIFACT EDI catalog, and a single CMA CGM integration reaches multiple brands in the group, since the Track and Trace API exposes CMA CGM, ANL, APL, CNC, and Containerships shipment events through the same endpoints. The practical implication: if you built one connection thinking it only covered "CMA CGM," check whether your contract and freight forwarder relationships also route through ANL, APL or CNC Line bookings, because they likely ride the same API keys.

What to check before and after the cutover

Portal migrations are a classic source of silent auth failures, not because the API itself breaks, but because client IDs, redirect URLs or sandbox endpoints get reissued and nobody notices until a booking submission starts failing in production. Before and after October's cutover, work through this list:

• Re-validate your OAuth2 client credentials or API keys in sandbox once the new portal is live. Don't assume existing tokens carry over unchanged.
• Check whether documentation and release-note URLs moved. Portal redesigns frequently restructure these paths, which breaks internal runbooks that link to specific changelog pages.
• If you use Out of Gauge, reefer or Shipper Owned Container (SOC) flows, re-test against Booking Request API v1.12.0 explicitly, since OOG support, dry and reefer cargo, multi containers and multi size/type, SOC, empty pick-up settings, VAS, inland haulage and HAZ are all live features that shipped weeks before the portal swap and are easy to miss in a quick smoke test.
• Confirm your EDIFACT fallback still works. CMA CGM runs its EDI catalog in parallel with the REST APIs, covering IFTSAI (schedules), IFTMBF (booking), IFTSTA (tracking), INVOIC (billing), so if the portal has hiccups during cutover, EDI-only shippers aren't forced off their existing message flows.
• Watch the public roadmap page for the exact Q4 timing of DCSA T&T 3.0, since CMA CGM states target dates by quarter and adjusts them.

The bigger pattern: DCSA is doing for ocean what OAuth did for parcel

CMA CGM isn't improvising its own event taxonomy here. It was a founding member of the Digital Container Shipping Association standardization initiative, and its Track & Trace API is one of the earliest and most complete carrier implementations of the DCSA v2.2.0 OpenAPI standard. The payoff CMA CGM itself points to is fairly concrete: switching to the DCSA standard improved reusability of this critical interface, thanks to standardized integrations in place of bespoke implementations, which reduced the costs involved in setting up partners as well as the cost of support. For shippers, the comparison point is Maersk, which runs its own DCSA-aligned tracking stack through Track and Trace Plus for detailed milestone history and MEC Tracking for event-level data across Maersk, Hamburg Sud, and Sealand containers. MSC does the same thing on its end, and its API supports DCSA Track and Trace versions 1.2 and 2.2, since MSC is also a founding member of DCSA. None of this means every carrier's event labels match. They don't; Maersk and MSC still use different wording for the same milestone. But the underlying data model converges, which is exactly what reduces the custom-mapping work your middleware has to do carrier by carrier.

Where this fits in a multi-carrier integration strategy

If you're already running a middleware layer that normalizes parcel, road freight and ocean bookings into one feed for your TMS or ERP, a CMA CGM portal relaunch is a line item to check off, not a fire drill. That's the entire argument for not maintaining 40 direct carrier connections in-house: platforms like Cargoson, nShift, Metapack and Descartes exist precisely so a single vendor's portal migration doesn't become your afternoon. Worth noting, though, that these platforms vary widely in how much ocean-carrier coverage they actually offer versus parcel-only networks, so don't assume your existing multi-carrier tool already has CMA CGM wired up to the new endpoints just because it handles your DHL and GLS traffic.

Practical checklist for the next two weeks

• Bookmark the new portal URL once it goes live and update any internal wiki links pointing to the old interface.
• Re-run your sandbox booking, schedule and tracking calls against the new portal before touching production traffic.
• Check webhook or event notification endpoint URLs for changes tied to the redesign.
• Confirm your EDIFACT fallback path still functions in case the REST portal has downtime during the cutover window.
• Set a calendar reminder to revisit the roadmap page in Q4 for the firm DCSA T&T 3.0 release date, and again in Q3 2027 if you're waiting on the DCSA-format Booking Request MVP.