NAUTIX and OpenMarine in plain English

Sooner or later a broker or dealer asks a portal how to publish a fleet of forty boats without typing them in, and is told: "Send us a NAUTIX feed" or "We can take OpenMarine." It sounds like a conversation for the technical department. It is really a conversation about how yacht data is described, and it is simpler than it sounds.

The problem both were created to solve

A yacht listing is a lot of structured information: type, builder, model, year, dimensions, engines, accommodation, equipment, price, location, description, photographs. If every portal invented its own layout, every broker would have to produce a different file for each one, and a field called "length" might mean overall, waterline or hull.

A shared format says: this is the name of each field, this is what it means, and this is how the file is arranged. Two systems that both speak it can exchange listings without anyone retyping.

What they are

OpenMarine is an older exchange format used for boat listing data, widely supported across the industry for many years. You will still meet it in the wild, especially with older systems.

NautiX is a newer XML interface developed by the Nautic Network, a group founded by boat portals to standardise how data is shared. It was designed to be more precise and to replace earlier standards such as Open Marine. The schema is published and open to use, and a file can be checked against it for validity. Its aim is high-quality data exchange through a clearly defined interface.

In practice: both are agreed ways of describing a boat in a file. NautiX is the more modern one, and the one you will most often be asked about today.

What it means for a broker

Publishing

If your system can produce a NautiX file, a portal that accepts NautiX can read your listings automatically. You maintain the yacht in one place, and the portal gets updates without anyone re-keying.

Importing

The same works in reverse. If a co-broker, builder or partner sends you a feed, you can load their yachts into your own system, ready for review, rather than typing each from a brochure.

Quality

A defined schema means a file can be validated. Missing mandatory fields, impossible values and malformed entries show up as errors rather than as wrong listings. That is a quiet but real benefit.

What a feed does not do

Be realistic about the limits.

• It does not fix bad data. A well-formed file containing a wrong year is still wrong. The standard guards the format, not the facts.
• Not every portal accepts it. Some use their own layouts or APIs, and some require manual entry.
• Mapping still matters. Your internal categories must translate into the standard's categories. The odd field will not fit neatly.
• Photographs travel differently. Typically the feed carries addresses of images, so they need to be hosted somewhere reliable.
• Updates have timing. A portal may collect a feed on a schedule, so a change may appear after a delay.

Questions to ask before you rely on a feed

1. Which portals actually accept it, and which format and version do they want?
2. How often do they collect updates?
3. What does the portal do with records it rejects, and will you be told?
4. How are withdrawn or sold yachts removed?
5. Can you see what was sent and when?
6. Who is responsible for each field, and who corrects it when it is wrong?

Why bother, if you only have a few boats?

Small brokerages sometimes assume feeds are for the large houses. The saving scales down as well as up: even a handful of yachts, listed on several portals, means a dozen places to correct each time a price changes. A feed does that work once. The better argument is not volume but reliability, since a machine does not forget the third portal.

A sensible routine

• Maintain each yacht carefully in one master record.
• Run completeness checks before any publication.
• Generate or send the feed from that record, never by hand-editing an exported file.
• Review rejection reports weekly.
• Remove sold and withdrawn yachts the same day.

Where Yachtbase fits

Yachtbase holds a deep yacht specification structured to be compatible with NAUTIX and OpenMarine. It can import NAUTIX XML, validate it and let you resolve conflicts before anything is saved, and it can generate NAUTIX feeds for partners, including a tokenised feed per partner, alongside an OpenMarine adapter. Availability on each portal depends on that portal's own acceptance.

In short

• Both are agreed ways of describing a boat in a file, so data can move between systems without retyping.
• OpenMarine is the older format. NautiX, from the Nautic Network, is the more modern one, designed to succeed it.
• Feeds improve consistency but cannot correct wrong information.
• Ask each portal which format, which version and how often.
• Keep one master record and generate feeds from it.
• Check rejections regularly and withdraw sold boats promptly.