You need to know, right now, whether a dredger is operating near a port, how fast it’s moving, whether it’s headed to your berth pocket, and when it will clear the channel. By the end of this post, you’ll be able to detect dredgers near any port, monitor a specific unit’s live AIS track and recent port calls, check expected dredger arrivals, and roll it all into a fleet dashboard using vessels-api.com.
What “dredger near a port” means for your stack
Dredgers change a port’s capacity in hours. If you run port operations, marine services, or channel maintenance planning, your application needs to:
- Detect dredgers within a defined radius of a port approach or anchorage
- Track a specific dredger’s live position, movement history, and current voyage
- See expected arrivals to coordinate windows and avoid conflicts with inbound traffic
- Assess time-in-port and port call counts to understand dredging cycles
- Manage multiple dredgers as a fleet in one request
vessels-api.com provides a single, consistent REST interface for all of the above. Every response is a predictable JSON envelope: {status, success, message, data}. Authentication is a single X-API-Key header across all endpoints.
Detect dredgers near a port approach
Start by mapping a radius around your port’s entrance or dredge site and filter to dredger ship types.
Endpoint: GET /vessels/nearby
Purpose: Return all vessels within a radius (nautical miles) of a lat/lon point. Filterable by ship_type. Useful to answer “is there a dredger working within 5 NM of the breakwater?”
Example cURL (30 NM around a sample position; filter for dredgers):
curl -H "X-API-Key: YOUR_API_KEY" "https://vessels-api.com/api/V1/vessels/track?mmsi=258785000&hours=48"
Sample JSON (structure and fields as returned):
{
"status": 200,
"success": true,
"message": "OK",
"data": {
"vessel": {
"imo": "9122556",
"mmsi": "258785000",
"name": null
},
"current_position": {
"latitude": 53.33708,
"longitude": 7.17993,
"speed_knots": 0,
"course_degrees": 212,
"heading_degrees": null,
"navigational_status": 5,
"timestamp_utc": "2017-01-24T04:07:04+00:00",
"age_minutes": 5152281,
"destination": null,
"eta": null
},
"predicted_eta": null,
"position_history": [],
"route": {
"departure_port": "HERACLIO",
"departure_time": "2026-04-27T21:35:36+00:00",
"destination_port": "HERACLIO",
"eta": null,
"distance_nm": null,
"avg_speed_knots": 17.1
},
"last_port_visits": [
{
"port_id": "156",
"port_name": "EMDEN",
"arrival_time": "2026-07-30T13:00:10+00:00",
"departure_time": null,
"duration_hours": null
},
{
"port_id": "10",
"port_name": "HERACLIO",
"arrival_time": "2026-04-20T12:00:00+00:00",
"departure_time": "2026-04-23T08:00:00+00:00",
"duration_hours": 68
}
],
"weather": null
}
}
How to use it:
- Use distance_nm to prioritize the closest dredgers to your operation area.
- speed_knots near zero with navigational_status indicating restricted maneuverability (common for dredging) signals active dredging.
- Cache results for a few seconds to a minute in your UI; AIS refresh is near real time, but your users don’t need sub-second polling.
Track a specific dredger in near real time
Once a dredger is identified, get its live position, up to 168 hours of history, active route, last port visits, and optional weather overlay.
Endpoint: GET /vessels/track
Purpose: Live AIS position plus history, route, predicted ETA, and recent port calls for a single vessel by MMSI or IMO.
Official cURL (documented MMSI 258785000, 48 hours history):
Official JSON response:
Field notes you will actually use:
- current_position.latitude/longitude, speed_knots, course_degrees: draw the dredger on your map and infer activity.
- current_position.navigational_status: 5 typically maps to restricted maneuverability (useful for dredging operations UIs).
- age_minutes and timestamp_utc: understand AIS record freshness; handle stale points gracefully.
- last_port_visits: anchor your dredging cycle analytics to real port events without polling a separate events feed.
- route.* and predicted_eta: when the dredger is in transit, show realistic ETAs into your work window.
Python example to fetch and display current dredger state
import requests
API_KEY = "YOUR_API_KEY"
MMSI = "258785000"
URL = "https://vessels-api.com/api/V1/vessels/track"
params = {
"mmsi": MMSI,
"hours": 48, # up to 168
"include_route": "true",
"include_predicted_eta": "true",
"include_weather": "false"
}
resp = requests.get(URL, headers={"X-API-Key": API_KEY}, params=params, timeout=15)
resp.raise_for_status()
payload = resp.json()
if not payload.get("success"):
raise RuntimeError(payload.get("message"))
data = payload["data"]
cp = data["current_position"]
print(f"Position @ {cp['timestamp_utc']}: {cp['latitude']}, {cp['longitude']}")
print(f"Speed {cp['speed_knots']} kn, Course {cp['course_degrees']}°, Nav status {cp['navigational_status']}")
route = data.get("route")
if route:
print(f"Route: {route['departure_port']} → {route['destination_port']}, avg {route['avg_speed_knots']} kn")
print(f"ETA (planned/predicted): {route.get('eta')} / {data.get('predicted_eta')}")
for visit in data.get("last_port_visits", []):
print(f"Visited {visit['port_name']} at {visit['arrival_time']}")
Implementation tips:
- All timestamps are UTC (ISO 8601). Convert once at the view layer.
- If age_minutes is large, surface a “stale” badge and hold off map animations.
- When history is empty (e.g., stationary dredging), render breadcrumbs conditionally.
Plan berth windows with expected arrivals
Ops teams need to know when dredgers will approach a port so they can deconflict with inbound traffic or coordinate tender supplies.
Endpoint: GET /port/expected-arrivals
Purpose: Returns vessels expected to arrive at a port with ETAs and origin.
Example cURL:
Sample JSON (showing dredgers if scheduled):
Use it to:
- Show a dredger ETA clock in your port control UI.
- Alert when a dredger’s ETA collides with peak inbound windows.
- Cross-reference with /vessels/track for live adjustments.
Quantify dredging cycles and port time
To understand how often a dredger calls your port and how long it stays at berth or anchorage, pull voyage statistics over a time window.
Endpoint: GET /vessels/analytics
Purpose: Aggregated statistics per vessel over a period (24h, 7d, 30d, 90d).
Example cURL (7-day analytics for a dredger by MMSI):
Sample JSON:
What to derive:
- Low avg_speed_knots with modest total_distance_nm indicates stationary dredging vs. transits.
- port_calls_count and total_time_in_port_hours quantify dredger utilization and downtime.
Manage multiple dredgers in one request
If you coordinate more than one dredger, you don’t want to fan out dozens of HTTP calls from your UI every second. Use the fleet batch endpoint.
Endpoint: POST /vessels/fleet
Purpose: Return positions, routes, and summary stats for multiple vessels in a single payload.
Example cURL:
Sample JSON:
How to wire it:
- Batch your dredger identifiers server-side and stream a single payload to the browser via SSE or WebSocket.
- Use the fleet summary to power compact KPIs on your dashboard.
Port situation awareness for traffic and constraints
In addition to dredger-specific feeds, you’ll often want to overlay broader port context.
Endpoint: GET /ports/data
Purpose: Retrieve a single port’s identifiers and live vessel counts (vessels_in_port, vessels_expected) for quick situational context.
Example cURL:
Use cases:
- Gate dredging windows when vessels_in_port spikes.
- Combine with /port/expected-arrivals to estimate peak congestion windows for safety zones.
Implementation details that save time
- Authentication: Send X-API-Key: YOUR_API_KEY on every call. There is no OAuth or per-endpoint auth variance.
- Units: Distances in nautical miles (nm), speeds in knots (kn), bearings in degrees, timestamps in UTC ISO 8601.
- Pagination: /vessels/search supports page and per_page (max 100). Most endpoints return lists within the data field without paging if scoped (e.g., nearby).
- Error handling: Check the top-level {status, success, message}. HTTP codes: 400 for invalid parameters, 401 for missing/invalid key, 404 if vessel/port not found, 422 for out-of-range (e.g., radius > 200 NM), 429 for rate limit, 500 for server errors.
- Caching: For map UIs, a 10–30s cache is a good baseline per track/nearby call; extend when age_minutes is large.
- Search: If you don’t know the MMSI/IMO, start with GET /vessels/search (query by name; filter ship_type=Dredger) to resolve identifiers.
End-to-end flow: “Is there a dredger near my port, and what’s its plan?”
- Use /vessels/nearby with your port’s lat/lon and ship_type=Dredger to detect candidates within 10–30 NM.
- For each candidate, call /vessels/track to get live speed/course and confirm active dredging (slow speeds, restricted nav status).
- Query /port/expected-arrivals to understand upcoming dredger approaches and align safety windows.
- If you manage multiple units, batch them via /vessels/fleet to keep the UI responsive.
- Pull /vessels/analytics weekly to quantify utilization, time-in-port, and port calls for planning and compliance reporting.
FAQ
Q: How do I filter only dredgers?
Use GET /vessels/nearby or /vessels/search with ship_type=Dredger. The nearby endpoint additionally supports radius and limit to scope results.
Q: What timezone are timestamps in?
All timestamps are UTC in ISO 8601 format. Display conversion should happen in your client based on user preference.
Q: How fresh is the AIS data?
Use current_position.age_minutes from /vessels/track to assess freshness per vessel. For near real-time UIs, surface a “stale” badge when age_minutes exceeds your threshold.
Q: Can I track history for more than a day?
Yes. /vessels/track supports hours up to 168 (7 days) for position_history. If history is empty, the vessel is stationary or no historical points were available in the window.
Q: How do I handle errors uniformly?
Every response has {status, success, message}. Check success before reading data, and branch on HTTP codes: 401 means check your X-API-Key, 422 often indicates an out-of-range parameter (e.g., radius > 200).
Build your dredger-awareness features now
Spin up your dredger-near-port workflow with a single API key and a consistent JSON model across tracking, nearby search, port arrivals, analytics, and fleet batching. Start by pulling the official /vessels/track sample above into your repo, then layer /vessels/nearby and /port/expected-arrivals to add real operational value. When you’re ready to go deeper, the references below cover every field and edge case you’ll need.