Why maritime software is broken, and what APIs actually fix

The state of things

A ship arrives at the pilot boarding place off Rotterdam. The terminal is not ready. The berth is still occupied. The pilot is on another job. The tugs are scheduled for a window that has already passed.

The ship anchors. It burns fuel. It waits.

This happens thousands of times a day across the world’s ports. It is not a rare event. It is the default. Ships spend five to ten percent of their time waiting to get into port, burning fuel they do not need to burn.

None of this is because the information is missing. The port knows when the berth will be free. The terminal knows when the cargo will be ready. The ship knows its own speed and fuel curve. The pilot station knows the pilot roster. The customs broker knows the cargo status.

Every single piece of the puzzle exists in a computer somewhere. The pieces just do not talk to each other.

That is the maritime software problem. Not missing data. Disconnected data.

The silo problem, stated plainly

A data silo is what happens when information that should flow between systems sits locked inside one of them instead.

The shipping industry runs on silos. Almost every maritime company has three to twenty different software systems in daily use. A typical medium-sized shipowner will have:

• A planned maintenance system for the engine room
• A crew management system for rostering and payroll
• A fleet management system for the commercial side
• A voyage reporting tool for fuel and noon reports
• An MRV system for emissions reporting
• A port call coordination platform
• A separate spreadsheet world for everything the above systems cannot do

Each of these was bought separately. Each was deployed at a different time. Each has its own login, its own database, its own way of naming things. They rarely speak to each other. When they do, it is usually through a CSV export that someone emails once a month.

The shore office spends its days acting as a human integration layer. Someone in operations pulls a fuel figure from the voyage reporting tool, checks it against the engine room log, copies it into the MRV system, and emails a summary to the commercial team. Every number crosses three screens and two coffee breaks before it becomes a decision.

Gartner puts the number at 87 percent of organisations struggling with disconnected data sources. In maritime, I would guess the real number is closer to 95. The industry just does not complain about it as loudly, because people have been working this way for so long that it feels normal.

It is not normal. It is expensive.

Silos

Connected

The real cost of disconnection

Let us put some numbers to it. These are not vendor marketing claims. These are figures from industry research, regulators, and published studies.

Fuel waste from poor port coordination. IMO analysis estimates that improved port call coordination can reduce fuel consumption by up to 20 percent per voyage. A study commissioned by the Low Carbon Global Industry Alliance found just-in-time arrival could result in an average CO2 reduction of 14.16 percent per voyage in container shipping. Desktop exercises with the Port of Rotterdam and Maersk showed 23 percent less fuel consumed in JIT arrival scenarios compared to normal operation.

Operational waste from fragmented systems. Industry studies cited in recent maritime digital research suggest poor data integration wastes 10 to 20 percent of operational potential. Operators running fully integrated systems report 8 to 14 percent fuel reduction from voyage optimisation alone, and up to 40 percent fewer manual errors.

Time lost waiting. Up to 15 percent of total GHG emissions from shipping occurs in port areas, according to SINTEF. A significant share of that is ships waiting for berths, tugs, or pilots that could have been scheduled better with shared data.

Time lost reporting. Ask any chief engineer what percentage of their shift goes into paperwork and reports. The answer is usually somewhere between 20 and 40 percent. Most of that work is copying data from one system into another because the systems cannot talk.

The industry has been optimising ships, fuels, and engines for decades. The next big lever is none of those things. It is how the systems talk to each other.

Why has this not been fixed already?

Fair question. The honest answer is a combination of four reasons.

Maritime software vendors sell platforms, not interfaces. The business model for most maritime software has been to sell a complete closed system. Integration was something you paid extra for, usually as a custom project that took six months and never quite worked. There was no incentive for a vendor to make it easy for your data to leave their system.

The industry is conservative, for good reasons. Ships are expensive, safety is paramount, and a bad software update at sea is not the same as a bad software update in an office. Caution is warranted. But the same caution that protects navigation systems has slowed the replacement of back-office systems that should have been replaced a decade ago.

Legacy systems are stickier than most industries see. Ship management software designed in 2009 is still in use on thousands of vessels today. It was not built to consume real-time data streams, push updates over modern connectivity, or integrate with port community systems that assume modern APIs. It was built to generate reports. Replacing it is a project. Most owners have avoided it.

Nobody has owned the standard. In banking, SWIFT forced a standard on a fragmented industry. In container shipping, DCSA is finally doing something similar. In air freight, IATA did it decades ago. Most of maritime outside container shipping has no equivalent body. Every company talks to every other company in its own way. Multiply that across thousands of ports and hundreds of thousands of ships and you get the current mess.

What is an API, in plain terms

An API is an agreement between two systems about how they will share information.

That is it. It is not magic. It is not complicated. It is an agreement.

Think of it like the receipt at a hotel front desk. You check out and they ask “email or printed?” Either way you get the same information. The difference is the delivery format. An API is the same idea for software. Two systems agree on a format, agree on where to send data, and agree on how to ask for it. After that, they talk without any human involved.

A real example. Say your ship completes a voyage. Without an API, your chief officer opens the voyage reporting software, fills in the fuel consumed, the distance sailed, the average speed, and the ports visited. Later, someone in the office opens the MRV reporting system and types the same numbers in again. Later still, the commercial team sees those numbers in a monthly PDF.

With an API, the voyage reporting system sends the voyage summary directly to the MRV system the moment the voyage closes. The MRV system already has the data. The commercial team sees it on their dashboard an hour later. No one typed anything twice.

That is the whole idea. APIs remove the copy-paste layer between systems.

Why events matter, not just APIs

There is a second concept that belongs next to APIs. It is called an event.

An API is how two systems talk. An event is what they talk about.

An event is a thing that happened in the real world, captured as structured data the moment it happens. “Ship departed Port A at 14:32 UTC.” “Fuel tank switched from HFO to MGO at 16:05 UTC.” “Main engine started at 08:00 UTC.” “Berth 7 became available at 11:40 UTC.”

Old software collected reports at the end of a period. The chief engineer filled in the noon report once a day. The port sent a “berth available” email when someone remembered. The operator logged the bunker change when they got around to it.

Event-based software captures the moment something happens, stores it with a timestamp, and makes it available to anyone who needs to know. The data becomes a stream of small, precise facts. Not a pile of forms filled in after the fact.

This matters for three reasons.

Events have a time. Traditional reports are snapshots. Events are a timeline. If you want to know what actually happened during a voyage, a stream of events is a log. A stream of reports is an interpretation.

Events can trigger actions. When the event “ship entered emissions zone” is captured, the MRV system can start counting. When the event “berth became available” is captured, the pilot station can be alerted. When the event “fuel level dropped below 20 percent” is captured, a bunker order can be drafted. None of this needs a human to notice and act.

Events compose. A voyage is not one thing. It is the sum of hundreds of smaller events. Once you have the events, you can build any report you want from them. Want a CII calculation? Pull the events. Want a charter party compliance check? Pull the events. Want to see if a particular vessel operator is gaming the noon report numbers? Pull the events. You cannot do any of that from PDF summaries.

This is the shift from “software that records what you type” to “software that records what actually happened.”

Report

Events

What “contextualised” business data means

One more piece. When APIs carry events, the events must carry business meaning, not just numbers.

A fuel consumption figure on its own is nearly useless. Was it main engine or auxiliary? In port or at sea? Laden or ballast? In which emissions zone? Against which charter party? Paid for by whom?

A voyage ID on its own is nearly useless. Which vessel? Which cargo? What grade of bunker? Which operator is reporting? Under which charter terms?

Contextualised data means every event and every API payload carries enough surrounding information to be meaningful on its own. Not a number in a cell. A number in a cell plus everything you need to understand what the number means.

This is why DCSA’s work on container shipping standards matters so much. They are not just defining where to send data. They are defining what each field means. When a carrier reports a “port call arrival event,” every carrier uses the same definition of what that is, what fields it must contain, what timestamps to use, and how to reference the vessel. That is the hard part of interoperability. The protocol is the easy part.

In 2025, DCSA published the unified VGM standard, which replaces the current mess of emails, spreadsheets, carrier portals, and EDI messages with a single API for verified gross mass. That standard came out of collaboration with Maersk, MSC, CMA CGM, Hapag-Lloyd, ONE, Evergreen, Yang Ming, HMM, and ZIM. These are not small players. They represent most of the world’s container capacity. When they agree on a standard, the standard becomes real.

Outside the container world, equivalent work is happening in pieces. The IMO’s Just-in-Time Port Call framework. The International Taskforce on Port Call Optimization. The EU MISSION project. DYNAPORT. Individual ports like Singapore and Rotterdam running their own digital coordination platforms. Progress is real but fragmented. The bigger picture is that the industry is slowly converging on the idea that open APIs with contextualised data are the foundation everything else is built on.

Who benefits, and how

Let me walk through each major stakeholder and show what APIs and events actually change for them.

For shipowners and operators

Today, if you want to know whether your fleet is operating efficiently, you wait for monthly reports. Then you open spreadsheets. Then you compare the numbers to last month. Then you ask the technical superintendent why Vessel X burned more fuel than Vessel Y. The answer comes back a week later, often after someone has gone onboard to check.

With connected systems and event streams, you see what is happening as it happens. Mizzen Digital’s reporting of integrated system adopters shows 8 to 14 percent fuel reduction through voyage optimisation, 20 to 30 percent faster decision cycles, 15 percent lower voyage costs, and immediate profit-and-loss visibility across fleets. You stop reacting and start steering.

The bigger prize is commercial. Clean, connected, contextualised data is what lets you make good decisions about chartering, speed, bunker buying, and vessel deployment. An owner who sees their real fuel-per-mile-per-cargo-ton by vessel and by route is a different commercial operator than one who sees a monthly PDF.

For charterers and cargo owners

Charterers want predictability. Cargo owners want visibility. Both currently get neither, because the information that would provide it is trapped in someone else’s system.

An API-enabled world means a charterer can watch the voyage unfold in real time. Position, speed, ETA updates, fuel consumption against the charter party curve, port call readiness. They stop relying on daily voice calls with the operator and start relying on a dashboard. When something goes wrong, they know within minutes, not days.

For the cargo owner, it is the difference between “my container is somewhere” and “my container will be discharged at 14:00 tomorrow and loaded onto the truck at 16:00.” Just-in-time arrival benefits the whole supply chain, not just the ship.

For ports and terminals

Ports live with the consequences of poor information. Ships arrive when they want to, not when the port is ready. Tugs are scheduled hopefully. Berths are allocated by a mix of first-come-first-served, political clout, and improvisation.

With shared APIs and event streams, ports can pre-book berths. They can coordinate tugs and pilots against a known arrival window instead of a hope. They can allocate their physical infrastructure based on real demand, not guesses. Singapore’s Maritime Port Authority runs a Just-in-Time Platform that connects over 150 port users for automated coordination of marine services. That is a preview of what every major port will do within five years.

The environmental story matters too. Fifteen percent of shipping emissions happen in port areas. Much of that is waste from vessels waiting, manoeuvring at low speed, or approaching at high speed to beat other ships to the berth. Coordination fixes a meaningful slice of this.

For software vendors

This is the part the industry does not talk about enough. Software vendors benefit from APIs more than almost anyone else, even though their instinct has been to resist.

A vendor with open APIs stops competing on feature completeness. They start competing on what they do well. If your planned maintenance system has open APIs, you do not need to also build a crew module, a voyage module, and a finance module. You build the best planned maintenance system in the market, and you let the customer connect it to the tools they already use. You stop trying to be everything. You start being excellent at one thing.

This is the “digital ecosystem” argument that shipping publications have started making in the last two years. The era of “we do everything, all in one platform” is ending. The era of “we do one thing brilliantly, and we connect” is starting. Vendors who get this early will win.

And importantly, open APIs make you investable. When your product plugs into any stack, you are a useful part of any fleet, not a replacement project. Replacement projects get deferred. Integration projects happen faster.

For crew

The unglamorous one. Crew on modern ships spend an enormous amount of their time on paperwork. Rest hour logs, maintenance reports, noon reports, bunker delivery notes, voyage summaries, customs documents, cargo handling reports. Every form is a separate system. Every system asks for the same basic information.

An API-connected ship fills in the common fields automatically. The vessel name does not need to be typed 200 times a day. The IMO number is not manually entered on every form. When a fuel change happens, the event is captured once and propagates to every system that cares. Crew get to spend their time on the things that need human judgement, not on paperwork.

Does it eliminate paperwork entirely? No. Does it cut it significantly? Yes. Every operator running event-based systems reports this as the most appreciated change on the ship.

What good looks like

Let me describe what a properly connected maritime operation looks like. Not in marketing terms. In practical ones.

You have a ship at sea. It is running a standard voyage. In the engine room, an OPC UA server is streaming data from the main engine and auxiliaries. On the bridge, navigation systems are producing position, heading, and speed data. In the engine control room, fuel flow meters are measuring consumption in real time.

All of this data flows into an onboard data layer. The data layer publishes events. “Engine started.” “Fuel flow rate changed.” “Position updated.” “Entered emissions zone.” “Exited emissions zone.” Each event has a timestamp, a vessel identifier, a voyage identifier, and whatever business context is relevant.

These events flow to shore through whatever connectivity is available. If the connection is good, events flow immediately. If it is not, they queue and sync when connectivity returns. No data is lost. No data is reported twice.

On shore, the events feed every system that needs them. The planned maintenance system sees the engine running hours. The MRV system calculates the emissions. The commercial team sees the voyage progress. The charterer sees the ETA. The port sees the incoming vessel. The bunker supplier sees that fuel is running low.

No one typed any of this. No one had to pull a report. No one had to ask anyone for an update. The data flows because the systems agreed on how to talk.

That is what APIs and events unlock. Not more software. Less of it. Less typing. Less chasing. Less arguing about whose number is right.

Where we go from here

The shift is happening. Slower than it should, but faster than it used to.

DCSA has become the de facto standards body for container shipping. Their API catalogue now includes Booking, Track & Trace, eBL, Port Call, Operational Vessel Schedules, Just-in-Time standards, and the new VGM standard. These are not theoretical. Major carriers are implementing them.

The IMO is pushing. The GreenVoyage2050 programme, the Low Carbon Global Industry Alliance, and the updated cybersecurity guidelines are all nudging the industry toward modern, connected, secure software.

The bigger players are building. Singapore’s Tuas Port runs event-driven architecture for terminal operations. Rotterdam’s PortXchange enables just-in-time arrivals at scale. Individual software vendors are starting to offer real APIs instead of CSV exports.

The obvious gap is the smaller operator and the smaller port. A medium-sized shipowner with 10 to 30 vessels is in the hardest position. They cannot afford to build it themselves. They depend on vendors who may or may not have modernised. They hear the talk but struggle to see the path.

This community exists for them.

We are not selling anything. We are not a vendor. We are a place where practitioners can learn what APIs are, how they work, which ones matter, and how to have better conversations with software suppliers. We will publish clear explainers. We will run a directory of maritime APIs so you can see what exists. We will moderate a forum where real people share what has worked for them and what has not.

The goal is simple. Make API literacy a standard skill in this industry. When a fleet manager can ask the right questions about integration, the industry starts to move. When vendors know their customers understand what they are selling, the products get better.

That is how the silos come down. Not through a single revolution. Through a lot of informed buyers finally asking the right questions.

---

Sources and further reading

This article draws on recent reporting and research from:

• Digital Container Shipping Association (DCSA) — standards publications, 2024–2025
• IMO GreenVoyage2050 Just-in-Time Arrival Guide
• Global Maritime Forum — Port Call Optimisation brief, 2025
• SINTEF DYNAPORT project documentation
• Maritime Executive editorial, March 2026 — AI, Analytics, and Automation
• Mizzen Digital — Integrated Maritime Software Solutions report
• Splash247 — “Think like a shipowner” commentary, June 2025
• Port of Rotterdam, TNO, Maersk, and MSC joint JIT exercise data
• Solace case study of SCCPL maritime terminal event-driven architecture

All data points and percentages in this article are cited from published sources. A consolidated list lives on the references page.

---

This is the first article in a series. Next week: what actually happens when you send an API request, explained without any code.