Asking whether a platform has an API is no longer a useful question, because every platform has one. The useful questions are narrower and almost nobody asks them before signing: what specifically needs to cross a boundary, in which direction, how often, who owns it when it breaks, and what happens to the data while it is broken. Those five determine whether an integration reduces the fragmentation in your operation or quietly adds to it — and industry commentary on evaluating maritime software puts that outcome plainly, noting that integration scope decides whether a platform reduces fragmentation or contributes to it. There is also a maritime-specific point that gets missed entirely. The hardest data movement problem in shipping is not connecting a maintenance platform to an accounting system. It is getting data off a vessel with intermittent satellite connectivity, without loss, in a way that survives a week offline — and that is presented as a product feature rather than as integration architecture, so it never appears on an integration evaluation. If a platform's own ship-to-shore synchronisation is weak, no external API repairs it, because the data never reaches shore in the first place. Start a free trial of Marine Inspection and test that link before assessing anything else.
The question everybody asks
Does it have an API?
Every platform does. The answer tells you nothing.
The five that actually decide the outcome
1What specific data needs to cross, and does anybody actually use it once it arrives
2In which direction, and if both, which system wins a conflict
3Pushed on an event or pulled on a schedule, and what that costs over satellite
4Who owns it when it breaks, on both sides, by name
5What happens to the data while it is broken, and how you find out
Every one of those has a right answer that is specific to your operation, and none of them can be answered from a feature list. An integration agreed without them is a permanent maintenance obligation entered into at the moment you know least about whether you need it.
What Actually Connects, and Why
The realistic integration map for a maintenance and inspection platform is narrower than most vendors imply, and each connection has a different justification. See it in a live demo and ask which of these your operation genuinely needs in the first year.
Finance and ERP
Work order cost and requisition data flowing outward so maintenance spend reaches the ledger without re-keying, and cost centre or vessel coding flowing back so the maintenance system knows how the finance function categorises things. Usually the first integration anybody asks for.
Justified when: somebody is currently re-typing purchase data between two systems
Procurement
Requisitions raised against a defect or a job syncing outward to a procurement platform, with confirmed orders returning for invoicing and payment. Maritime procurement integrations of this shape are established and the pattern is well understood.
Justified when: parts ordering already has a separate system with a supplier network
Noon reporting and performance
Voyage data, bunker consumption, port activity and emissions figures. Established platforms in this space include vessel reporting systems from classification-linked providers and independent performance tools, several with built-in validation to reduce reporting errors, supporting MRV and IMO DCS obligations.
Justified when: running hours or fuel data should drive maintenance intervals
Crewing
Who is aboard, in what rank, with which certificates current — so that a job can be assigned to somebody actually on the vessel and competent to do it, and so that a certificate expiry does not have to be tracked in two places.
Justified when: crewing is a separate system and assignment errors are recurring
Class and flag portals
Survey positions, conditions of class and certificate status. Frequently the integration people most want and the one least available, because societies expose data on their own terms and coverage varies considerably between them.
Justified when: available at all — check with your own society before scoping it
Ship to shore
The vessel's own data reaching the office and the office's changes reaching the vessel, across intermittent connectivity. The highest-volume and hardest movement in the whole architecture, and the one almost never assessed as an integration because it arrives labelled as a feature.
Justified always, and it is the one to test first
Push or Pull Decides the Maintenance Burden
This is the architectural choice with the largest long-run consequence, and in shipping it has a cost dimension that other industries do not carry. Sign up for Marine Inspection and establish which model each proposed integration uses.
Pull — polling
The receiving system asks on a schedule: every fifteen minutes, every hour, overnight. Simple to build, easy to reason about, and it makes a request whether or not anything changed. Most requests return nothing and every one of them costs something.
Push — webhooks
The originating system notifies the other when something actually changes, allowing real-time synchronisation of changes with an external system. Fewer transactions, closer to real time, and it requires the receiving end to be reachable and to handle a message arriving at any moment.
Why it matters more at sea
Polling a vessel-side system over satellite generates traffic on a link you pay for by volume, most of it returning no change. Published shipowner guidance already lists satellite communication costs among the hidden expenses of maritime software, noting that poorly optimised synchronisation generates additional traffic. A polling interval chosen carelessly is a recurring bill on every vessel, every day, forever.
Ask the specific question rather than the general one: for each integration, is this push or pull, and if pull, at what interval and how much data does a request move when nothing has changed. A vendor who has thought about maritime deployment will have an answer. One who has only deployed ashore will not have considered that the network is metered.
Test the ship-to-shore link before you evaluate a single external connector
Put the app in airplane mode, complete a full round with photographs and voice notes, leave it disconnected for a realistic period, then reconnect and watch what happens. Does everything arrive, do the capture timestamps survive rather than being replaced by upload times, and does a week of accumulated data sync without flooding the link. That test tells you more about a platform's integration engineering than any API documentation, because the vessel link is the hardest thing it does.
Direction, and the Conflict Rule
Bidirectional integrations are twice the value and considerably more than twice the difficulty, and the difficulty concentrates in one question that is easy to defer and expensive to defer. Schedule a walkthrough and settle the conflict rule before anything is built.
One way out
The maintenance platform is the source
Work orders, costs and requisitions flow to finance; nothing flows back. Simplest to build, simplest to debug, and sufficient for most first integrations. If somebody proposes bidirectional, ask what specifically needs to come back and whether a person could enter it in ten seconds instead.
One way in
Another system is the source
Crew lists, cost centre structures, vessel particulars or noon report figures arriving and being read rather than edited. Also straightforward, provided everyone understands that the receiving system does not own those records and cannot correct them locally.
Both ways
Which requires a conflict rule, agreed in advance and written down
If the same record is changed in both systems between synchronisations, one change survives and one is lost. Which one, and does anybody find out? Common answers are last-write-wins, source-system-wins per field, or flag-for-human-review — each defensible, none automatic. The rule needs to exist before the first conflict, because the first conflict is when somebody discovers a value they entered has silently reverted. Access permissions are typically controlled at user level with separate read, write and message-based rights, so scoping write access narrowly is the cheapest way to reduce the surface area.
The Translation Problem
Field mapping is the easy half. The harder half is that the two systems hold different concepts, and generic platforms frequently lack the maritime ones entirely. Start a free trial and check whether the concepts survive the crossing rather than just the fields.
What generic systems lack
Commentary on evaluating maritime platforms is direct about this: generic ERP systems adapted for shipping often lack the operational depth maritime workflows require — noon report structures, ISM documentation logic, alignment with vetting frameworks, and vessel certificate management with class-specific expiry rules. Those are not fields; they are concepts with behaviour attached.
What that means in practice
A maintenance work order carries an equipment reference, a criticality, a survey relevance and possibly a class condition. A finance system holds a cost line with a code. Mapping the amount is trivial; deciding what happens to the survey relevance when the record crosses is a design decision, and the usual outcome is that it does not cross at all.
The rule worth adopting
Send the minimum that the receiving system can genuinely act on, and keep the maritime richness where it belongs. An integration that flattens a maintenance record into a cost line is correct. One that attempts to represent class survey logic inside an accounting system is an ambition that will be maintained by somebody for years and used by nobody.
Every integration is permanent. Build the ones where somebody is currently re-typing data, and defer the rest until somebody asks twice.
Design for the Failure, Not the Success
Integrations spend most of their life working and are judged entirely on what happens when they do not. Book a walkthrough and put every one of these questions in writing before development starts.
Where does the data go while it is down
Queued and replayed when the connection returns, or dropped. Queued is the only acceptable answer for anything that matters, and it needs a stated queue depth and a stated behaviour when the queue fills.
How does anybody find out
An alert to a named person, or silence until somebody notices a report looks wrong three weeks later. Silent failure is the normal failure mode of an integration nobody monitors, and it is worse than an outage because the data diverges without anyone knowing.
What happens to a partial transfer
If a batch stops halfway, is the whole thing rolled back or is half of it now in the receiving system. Ask specifically, because the answer determines whether a failure leaves you with a problem or with two systems quietly disagreeing.
Who owns it, on both sides
A named person at each end, not a department and not a ticket queue. Integrations break at the boundary, which is precisely where ownership is usually ambiguous and where two vendors can each reasonably say it is the other one.
What happens when either system updates
Versioning, deprecation notice periods and who is obliged to tell whom. An integration built against an unversioned endpoint is a dependency on somebody else's release schedule, and you will find out about a change from a failure rather than from a notice.
How do you reconcile
A periodic comparison proving the two systems still agree — record counts by type, totals where they exist, spot checks on samples. Without it, divergence accumulates invisibly, and the first time anybody checks is during an audit or a dispute, which is the worst moment to discover it.
What to Ask Before Signing
These separate a platform with a real integration story from one with an API page. Ask them of every candidate, and ask the same questions of whichever system sits on the other side. Start a free trial and put them to us as readily as to anybody else.
Table 1: Integration Questions for the Vendor
| Area | The question | A real answer | What should worry you |
|---|---|---|---|
| Tier inclusion | Is API access included at our tier, or priced as a connector? | A stated position in writing, with any per-connector cost named | Included in principle, quoted separately in practice |
| Documentation | Can I see the API documentation now, without signing anything? | A public reference you can read and evaluate today | Documentation available only under agreement, which usually means thin |
| Style and events | Is it REST, and do you support webhooks as well as polling? | Both, with event types listed and a stated retry policy | Polling only, which becomes a satellite cost on every vessel |
| Rate limits | What are the limits, and what happens when we hit them? | Published numbers and defined behaviour at the ceiling | No limits mentioned, which means you will find them in production |
| Permissions | Can access be scoped separately for read, write and event actions? | Granular control at user or key level, demonstrated | One credential with full access, which is a governance problem |
| Versioning | How are breaking changes handled, and what notice do we get? | Versioned endpoints and a stated deprecation period | Continuous change with no version, which makes it your problem |
| Bulk export | Can we extract everything, not just query it record by record? | A bulk mechanism, because an API is not an exit route on its own | Only per-record endpoints, which makes leaving expensive by design |
| Failure behaviour | What happens to data during an outage, and who is alerted? | Queue with a stated depth, and alerting to a named person | Silence, which is how integrations diverge for months unnoticed |
| Precedent | Which system exactly like ours have you connected to before? | A named integration and a contactable customer who runs it | A logo grid with no reachable reference behind it |
Sequencing, and What to Refuse in Phase One
The single most reliable way to turn a short implementation into a long one is to include integrations before the core platform is in use. See it in a live demo and agree the phasing before the statement of work is drafted.
Table 2: Integration Phasing
| Phase | What belongs here | Why | The risk of moving it earlier |
|---|---|---|---|
| Phase zero | Ship-to-shore synchronisation, tested properly | It is the platform's hardest data movement and everything depends on it | None — this is the one to test before buying, not after |
| Phase one | Nothing. Core inspection and maintenance, in use, on real vessels | Integration effort is consistently underestimated at twenty to forty percent of implementation | A rollout consumed by connector work before anyone has used the system |
| Phase two | The one integration where somebody is currently re-typing data daily | The clearest justification available, and easily measured afterwards | Building three at once and being unable to attribute the benefit |
| Phase three | Whatever people asked for twice after using the platform for a quarter | Requests that survive a quarter of real use are real requirements | Building from a wish list gathered before anyone knew the workflow |
| Never | Integrations nobody has a named user for | Each one is a permanent obligation with an owner, a version dependency and a failure mode | A connector maintained for years and consulted by nobody |
| Reconsider | Anything replicating maritime logic inside a non-maritime system | Generic platforms lack the concepts and will represent them badly | Survey logic in an accounting system, maintained forever, trusted by nobody |
| Check first | Class and flag portal connections | Availability and terms vary considerably between societies and registers | Scoping an integration to a source that will not expose the data |
| Always | Bulk export, whether or not you integrate anything | The record has to outlive the platform, the manager and sometimes the vessel | Discovering the exit cost at the moment you need to leave |
2026 INTEGRATION REALITY
Integration availability and terms vary widely and change frequently. The systems named as integration categories here — finance and ERP, procurement, noon reporting and performance platforms, crewing, and class or flag portals — describe the landscape rather than any specific compatibility. Whether a particular connection exists, what it costs, and at which tier it is available are questions for the specific vendors on both sides, and answers should be obtained in writing before scoping work. Class and flag data access is the least predictable. Societies and registers expose data on their own terms and coverage differs considerably; confirm with your own before planning around it. The satellite cost point is real but unquantified here. Published shipowner guidance identifies poorly optimised synchronisation as generating additional VSAT and Starlink traffic; the magnitude depends entirely on architecture, so ask for measured figures rather than assurances. This page is published by a software vendor, and every question in Table 1 is one we should be asked as readily as any competitor.
Frequently Asked Questions
What should I ask instead of whether a platform has an API?
Five things, none of which appear on a feature list. What specific data needs to cross a boundary, and whether anybody will actually use it once it arrives. In which direction, and if both, which system wins when the same record changes in each between synchronisations. Whether it pushes on events or is polled on a schedule, and what that costs over a metered satellite link. Who owns it when it breaks, named, on both sides. And what happens to the data while it is broken — queued and replayed, or lost. Commentary on evaluating maritime platforms puts the stakes plainly: integration scope decides whether software reduces fragmentation or adds to it.
Why does push versus pull matter so much at sea?
Because the network is metered and most polling requests return nothing. Polling asks on a schedule whether or not anything changed; webhooks notify only when something does, enabling real-time synchronisation of changes with an external system. Ashore the difference is mainly architectural tidiness. On a vessel it is a recurring cost — published shipowner guidance lists satellite communication among the hidden expenses of maritime software, noting that poorly optimised synchronisation generates additional traffic. Ask, per integration, whether it is push or pull, at what interval, and how much data a request moves when nothing has changed.
What is the hardest integration in a fleet?
The one nobody evaluates: ship to shore. Getting vessel data ashore across intermittent connectivity, without loss, in a way that survives a week offline and does not flood the link on reconnection, is the highest-volume and most difficult data movement in the whole architecture. It arrives labelled as a product feature rather than as integration engineering, so it never appears on an integration checklist. Test it directly — airplane mode, a full round with photographs and voice notes, a realistic disconnected period, then reconnect and check that everything arrives with capture timestamps intact rather than replaced by upload times.
Should integrations be bidirectional?
Only where there is a specific reason, because bidirectional is considerably more than twice the difficulty of one-way. The difficulty concentrates in a single question: if the same record changes in both systems between synchronisations, which change survives and does anybody find out. Common rules are last-write-wins, source-system-wins per field, or flag-for-human-review — each defensible, none automatic, and the rule has to exist before the first conflict rather than after somebody discovers a value they entered has silently reverted. Since permissions are typically controlled separately for read, write and event actions, scoping write access narrowly is the cheapest way to shrink the problem.
Why do maritime integrations lose meaning even when the fields map?
Because the two systems hold different concepts, and generic platforms frequently lack the maritime ones. Industry commentary notes that generic ERP systems adapted for shipping often lack the operational depth maritime workflows require — noon report structures, ISM documentation logic, alignment with vetting frameworks, and vessel certificate management with class-specific expiry rules. A maintenance work order carries an equipment reference, a criticality and possibly a class survey relevance; a finance system holds a cost line with a code. Mapping the amount is trivial. The right rule is to send the minimum the receiving system can genuinely act on and keep the maritime richness where it belongs.
When should integrations be built?
After the core platform is in use, not alongside it. Integration effort is consistently underestimated at twenty to forty percent of implementation effort, and including connectors in phase one is the most reliable way to convert a short implementation into a long one. A sensible sequence is: test ship-to-shore before buying anything; run phase one with no external integrations at all; build in phase two the single integration where somebody is currently re-typing data every day, because that has the clearest justification and is easy to measure; and consider in phase three whatever people asked for twice after a quarter of real use. Requests that survive a quarter are requirements; the rest were wishes.
Integration scope decides the outcome
Every Connector You Build, You Maintain Forever
Test the ship-to-shore link before anything else, because it is the hardest data movement in the architecture and no external API compensates for it. Establish push or pull per integration and what polling costs on a metered link. Settle the conflict rule before building anything bidirectional. Send the minimum the receiving system can act on and keep maritime logic where it belongs. Name an owner at each end and design for the failure rather than the success. Then build one integration — the one where somebody is currently re-typing data every day — and let everything else wait until it has been asked for twice.
.png)
.png)
