Ports

Port line-up data sources

Published 8 August 2026 · updated 17 October 2026

A port line-up is the port authority's own berthing schedule. It shows which vessel, which berth, which cargo, which agent, and in what order. There is no world line-up feed. Anyone who offers one is offering something else.

Why no vendor sells a global line-up

There is nothing to buy. Every port authority publishes on its own, in its own format, on its own timetable, or not at all. In practice the formats range from a proper JSON API behind a modern website, to a daily spreadsheet, to a PDF, to an HTML page that changes its layout without warning.

So to cover a port, you must write and maintain a parser (a program that reads the data) for that one port. You must keep it working while the publication changes with no warning and no change log. That is the whole reason coverage is sold port by port, not as a feed.

The four formats a publication comes in

Here they are, ranked by how long a parser keeps working in real use.

Format	What it costs to maintain
A documented API	The best case, and the rarest. Antwerp-Bruges, Rotterdam and Montreal each publish vessel schedules that a machine can read, and a few terminal operators do the same for their own berths. The fields have names, changes usually come with a version number, and a parser written once keeps working. Almost no dry cargo port outside northern Europe is in this group.
A spreadsheet published on a schedule	Workable. The columns are stable enough to rely on, and the file is easy to download. It breaks when a person edits the workbook: a merged cell, a renamed sheet, a note typed into a data row. None of these changes are announced.
A daily PDF	Expensive. The page layout is the structure, so a change of layout is a change of format. A table split across two pages must be put back together before anyone can read it.
An HTML page	Cheap to start, but the maintenance never ends. It works until the authority redesigns its website, which nobody announces. Then it quietly returns nothing or, much worse, returns the wrong column.

The dangerous failure is not the parser that breaks. A parser that breaks shows an error, and someone looks at it. The dangerous parser is the one that keeps returning rows after the publication has changed. An old or shifted berthing order looks exactly like a current one, and nothing in the document says otherwise. So any tool that imports a line-up must record when it last read the source successfully. It must show that date next to the data, not hide it in a log.

What a line-up actually contains

Field	Notes
Vessel name	As the authority writes it. Often a former name.
Berth	The main purpose of the document.
Cargo	The goods, and often the quantity.
Agent	Useful, and rarely available anywhere else.
ETA / ETB / ETD	Expected arrival, berthing, departure.
Status	Waiting, working, sailed.
IMO number	Never. No authority publishes one.

The three time fields mean different things, and authorities do not use them consistently. ETA is when the ship is expected to arrive off the port. ETB is when it is expected at the berth. The gap between them is the congestion that the document exists to show. A line-up with only one date, and no label, has lost the information a broker reads it for.

The matching problem

There is no IMO number, so every line must be matched to a hull by name. Names are a very poor way to identify a ship. Different ships share them: one register of 53,283 hulls held 2,359 shared names. And names change: 11,869 hulls in Port State Control data have been inspected under more than one name.

So a match is a guess with a level of confidence. Any tool that matches must show the authority's original text next to the hull it chose. It must never replace one with the other. A line-up that quietly rewrites SEA FUJI YAMA to a register entry has thrown away the only proof of what was actually published.

Two things improve the guess, without pretending it is certain. First, a cargo quantity on the line narrows the choice to hulls that could carry it. This usually settles a clash between two ships with the same name. Second, a name history solves the problem of renamed ships. The authority often prints a name the hull lost when it was sold years ago. A matcher that knows only current names will invent a new ship instead of finding the right one. The ranking that comes from both is explained in ship names change, and they are not unique.

A row that cannot be matched is not a failure. It is a row for a person to check, and the tool must set it aside for review. It must not force the row onto the nearest hull, and it must not drop it. Forcing it gives a berth to the wrong ship. Dropping it makes the line-up quietly incomplete, which is worse, because nothing on the screen says a row is missing.

Why a line-up is not an arrival list

An arrival list built from AIS (the ships’ automatic position signals) is a different document with a different meaning. In AIS, the crew types the destination as free text, often shortened or out of date. Across 94,337 fixes we measured, 86% carry an ETA, so the problem is not an empty field. The problem is that only about half of those destinations match a real port. And an ETA is a statement by the crew about where the ship is going. It is never a berthing order from the port. If you present one as the other, you quote an order that does not exist.

This difference remains however much the AIS side improves. A vendor may match the free text to a real port and attach a usable arrival time. What you have is still a statement of intent typed on the ship’s bridge. It has no berth, no cargo, no agent, no order and no authority behind it. Under its own name, it is a useful document. Under the name “line-up”, it is a dangerous one. The same argument, from the chartering side, is in position list vs AIS vs port line-up.

What to do about the ports nobody publishes

Most of the world's berths are in this group, and paying more does not change that. For those ports, the line-up exists only in the agent's daily report. It arrives by e-mail to whoever asked for it, in whatever format that agent uses. You cannot buy it as a data source. It is often better than one, because the agent is actually there.

This sets a realistic scope for any tool. The ports worth building a parser for are the ports a particular desk actually trades. They are not a fixed list chosen once and never changed. A desk that works the Arabian Gulf and the west coast of India needs four or five ports covered properly. It gains nothing from a hundred ports where it never fixes ships.

References

IMO, Revised Guidelines for the Onboard Operational Use of Shipborne Automatic Identification Systems (AIS), resolution A.1106(29), 2015. Destination and ETA are manually entered at the start of the voyage. imo.org
Port of Antwerp-Bruges, PortStays and PortVoyages API. portofantwerpbruges.com
Port of Rotterdam, API developer portal. portofrotterdam.com

Position list vs AIS vs port line-upThree things people often mix up in chartering: where a ship is, when it is free next, and what the port authority expects at the berth. Ship names change, and they are not uniqueNames repeat and names change. Why a name is the worst way to identify a hull, and the ranked match that works instead. The IMO numberSeven digits that stay with a ship for its whole life. How the check digit works, and why MMSI cannot replace it.

Neptune Atlas

Neptune Atlas does not import port line-ups and this version does not plan to, for the reason above: every port needs its own parser for a publication that changes without notice, and a broking desk must never be shown a berthing order the software cannot actually see. What it does carry is where a hull is and the destination its crew has entered, drawn from the same feed as the live map and labelled as the crew's statement, not as a berth. Every paid plan starts with 7 free days. A card is needed to start them, and cancelling before they end costs nothing.

Try 7 days free Ship chartering software for brokers What each plan includes