# Keep an auditable vessel port and berth call log in Airtable

> Every four hours, log each arrival, departure and docking for your fleet in Airtable so laytime and demurrage claims rest on hard timestamps.

- Workflow type: code
- Services: MarineTraffic, Airtable, Slack Bot
- Categories: Operations
- Published: 2026-08-07

## What it does

- Checks your vessel watchlist every four hours and pulls the last seven days of port arrivals, departures, berthings and unberthings.
- Adds only the movements that are not already in your Airtable log, one row each with vessel name, IMO number, port, berth or terminal, event type and the UTC time.
- Never writes the same movement twice, even though every run deliberately re-checks a full week of history.
- Posts a short Slack note when a vessel docks or leaves a berth, and stays completely silent when a run finds nothing new.

## What you'll need

- A MarineTraffic subscription that includes the vessel port calls service, plus the key issued for it.
- Optionally the separate berth calls subscription and its own key, if you want berth and terminal level detail and the docking alerts. The workflow still runs without it.
- An Airtable base with a table to hold the movement log.
- A Slack workspace and the channel your operations team actually watches.
- The IMO numbers of the vessels you want on the watchlist.

## Prompt

On a cron trigger every four hours, keep a clean port call and berth call log for my tracked fleet in Airtable, so we hold an auditable movement record for laytime and demurrage claims instead of rebuilding one from emails after the fact. Build this as a code workflow. Every step is deterministic (fetch two endpoints, diff against stored rows on a composite key, insert, notify), and there is no judgement call anywhere in the chain.

Keep the vessel watchlist as a configurable input at the top of the workflow, with vessels identified by IMO number. For each vessel on the watchlist, call the MarineTraffic Single Vessel Port Calls operation over a rolling seven day lookback ending at the current UTC time.

Also call MarineTraffic Single Vessel Berth Calls for the same vessel over the same seven day window, to capture berth level dockings and undockings. Treat this half as optional. The port calls service and the berth calls service are separately purchased MarineTraffic products, each with its own 40 character API key, so someone holding only the port calls subscription should still get a working arrival and departure log. If no berth calls key is configured, skip the berth half cleanly and carry on rather than failing the run.

Before writing anything, read the existing log with Airtable List Records so you know what is already stored. Filter that read to a window slightly wider than the lookback, around eight days, so the comparison stays bounded as the table grows. Page through the results using the offset value until Airtable stops returning one, because if you only read the first page the deduplication will silently miss rows that fell on a later page.

Deduplicate on the combination of IMO, port, event type and UTC timestamp. That composite key is the single most important detail in this workflow. The lookback windows overlap heavily by design: MarineTraffic is not a poll provider and emits no webhooks for this data, so a rolling window plus composite key dedupe is what substitutes for a real poll trigger. Getting the key right is what makes it safe to re-read the same week on every single run.

Write only the events that are not already stored, using Airtable Create Records, one row per arrival or departure. Each row carries vessel name, IMO, port, berth or terminal, event type and the UTC timestamp. Create Records accepts at most 10 records per request, so batch the new rows in chunks of 10, and stay under Airtable's limit of 5 requests per second per base.

Keep every timestamp in UTC and label the column that way, for example 'Event Time (UTC)', since a demurrage argument turns on timezone. All MarineTraffic timestamps are already UTC, so store them exactly as returned and never convert to local time. If a speed column is added later, note that MarineTraffic returns SPEED in knots multiplied by 10, so it needs dividing by 10 before storing. Most of these legacy MarineTraffic endpoints return the whole result set in a single response with no paging, so no pagination handling is needed on that side.

For each newly recorded berthing and unberthing, post a short message to our operations Slack channel using the Slack Bot Send a Message operation, so the team sees dockings as they land. One message per new berth event, naming the vessel, the port, the berth or terminal, whether it docked or undocked, and the UTC time. Keep quiet when a run finds nothing new: if there are no new events, write nothing and post nothing.

## How to customize

- Change how often it runs, or widen the seven day lookback if a vessel tends to report late.
- Add or remove vessels on the watchlist by IMO number as your fleet changes.
- Decide which movements deserve a Slack ping, or route them to a different channel.

## FAQ

### Will this create duplicate rows if it runs every four hours?

No. Every run deliberately re-reads a full week of history, then matches each event against what is already stored using the combination of IMO number, port, event type and exact UTC time. Anything already in the log is skipped, so the overlapping windows cannot double write a row.

### Do I need both the port calls and the berth calls subscriptions?

No. Port calls alone gives you a complete arrival and departure log. Berth calls are a separately purchased product with their own key, and they add berth and terminal level detail plus the docking alerts. If you do not have that subscription, the workflow simply skips the berth half and keeps running.

### What timezone are the timestamps in?

Everything is stored in UTC and the column is labelled that way on purpose. A demurrage argument can turn on timezone, so the log never quietly converts times to a local clock.

### Why keep my own copy instead of just looking it up when a claim comes in?

MarineTraffic holds berth call history only from July 2017 and port calls from January 2015. Keeping your own durable copy means the evidence sits in a system you control, in a format your team can cite, without re-querying history every time a claim is raised.

### Can I use this for laytime and demurrage claims?

It gives you a consistent, timestamped movement record to work from, which is usually the hard part. Most teams pair it with their statements of fact and notices of readiness rather than relying on any single source on its own.

Use this prompt in General Input: https://www.generalinput.com/prompts/keep-an-auditable-vessel-port-and-berth-call-log-in-airtable