# Global Maritime & Vessel Sanctions Monitor (`stefano_seggio/actor-19-maritime-sanctions-monitor`) Actor

Extracts sanctioned-vessel records from the OFAC SDN List (1,540 vessel entries), cross-referenced against the UN Consolidated List by IMO number. Paris MoU, Tokyo MoU, and IMO GISIS were checked and rejected as CAPTCHA/login-gated - see README.md.

- **URL**: https://apify.com/stefano\_seggio/actor-19-maritime-sanctions-monitor.md
- **Developed by:** [Stefano Seggio](https://apify.com/stefano_seggio) (community)
- **Categories:**
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $0.50 / 1,000 sanctioned vessel records

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## Global Maritime & Vessel Sanctions Monitor — Apify Store Overview

**Actor ID:** `dR68wHyuOLS2WEhmo` · **Store URL:** https://apify.com/stefano\_seggio/actor-19-maritime-sanctions-monitor · **Version:** 2.0

***

### Executive Summary & Business Use Case

The Global Maritime & Vessel Sanctions Monitor extracts every **vessel-type entry** from the **US Treasury OFAC Specially Designated Nationals (SDN) List** — the official, government-published list of individuals, entities, and vessels whose US-jurisdiction assets are blocked — pulled directly from OFAC's own live XML export (`sanctionslistservice.ofac.treas.gov/api/PublicationPreview/exports/SDN.XML`, 1,540 `sdnType=Vessel` entries out of 19,329 total SDN entries at last live count). Each vessel's IMO number is additionally cross-referenced, when enabled, against the **UN Security Council Consolidated Sanctions List** (`scsanctions.un.org`) by matching the IMO number against the free-text designation fields of UN entity/individual records — the UN list has no dedicated vessel record type of its own, so this is an IMO-based corroboration signal, not a second structured vessel feed. Three other candidate sources named in this actor's original brief — Paris MoU/EMSA THETIS, Tokyo MoU/APCIS, and IMO GISIS — were live-checked and explicitly rejected as CAPTCHA- or login-gated (see the Technical Features section below); this actor only ever touches genuinely open, unauthenticated government file downloads.

This data is built for teams whose job is to know whether a specific vessel is currently sanctioned, not to price a transaction — OFAC's SDN List blocks a vessel's assets, it does not carry a monetary designation value, and the actor's own README says so plainly. Three concrete, real use cases follow directly from that: **trade compliance and denied-party screening teams** at banks, freight forwarders, and commodity trading houses screen a vessel named on a bill of lading, charter party, or letter of credit against `programs`/`imoNumber` before agreeing to finance, insure, or move a shipment on it. **Marine insurance and P\&I club underwriting and claims teams** screen a prospective hull, cargo, or liability risk before binding cover, then run this actor on a recurring schedule with `onlyNew` enabled so a vessel already on cover that gets newly designated, has its sanctions program change, or is later delisted surfaces automatically rather than being caught in a periodic manual re-check. **Shipping agencies, charterers, and port/terminal compliance desks** use `programFilter` (e.g. `["IRAN"]`, `["DPRK2"]`, `["RUSSIA-EO14024"]`) to run a narrow, trade-lane-specific watch — for example an Iran-sanctions-focused desk monitoring only vessels newly added to or dropped from the `IRAN` program, rather than the full 1,540-vessel list.

### Technical Features & V2 Architecture Highlights

**Two verified-open sources, two explicitly rejected ones.** Both live data sources are plain, stateless, unauthenticated file downloads (a bare `fetch()` with default redirect-following and exponential-backoff retry on network failure and HTTP 429/503 is the entire client, `src/http.ts`) — no headless browser, no proxy, no CAPTCHA-solving anywhere in this actor. The rejected sources were each verified with a concrete, documented technical reason: **Paris MoU / EMSA THETIS** redirects into a Keycloak OpenID Connect login screen (`am3.emsa.europa.eu/realms/emsa/protocol/openid-connect/auth`) on every request; **Tokyo MoU / APCIS**'s public search form carries a literal `<input name="captcha">` field; **IMO GISIS**'s `robots.txt` disallows the relevant paths and its public module is session/registration-gated for real search. None were force-scraped.

**Named, cross-run key-value-store delta persistence.** When `onlyNew` is enabled, the actor opens a **named key-value store, `actor-19-maritime-sanctions-monitor-delta-state`** (`src/state.ts`) — deliberately not `Actor.getValue()`/`setValue()`, which resolve to the store associated with the current run and would not survive between scheduled runs. This store persists, per vessel `uid`, a dual fingerprint pair plus enough identity (`vesselName`, `imoNumber`) to synthesize a meaningful `DELISTED` record later without re-fetching data that, by definition, is no longer in the feed. State is capped at 5,000 entries (oldest by `lastSeenAt` evicted first) and is REPLACED wholesale on a complete, untruncated run but MERGED onto prior state on a `maxItems`-truncated run, so vessels beyond a truncated walk's cutoff are never wrongly forgotten and re-reported as "new" later.

**Dual content-fingerprint design, not a single hash.** `src/fingerprint.ts` computes two independent SHA-1 hashes per vessel: a `statusFingerprint` over the vessel's sorted `programs` list alone (the closest thing to a "status" this domain has — a still-listed vessel can be added to or dropped from one sanctions program without being delisted outright), and a `contentFingerprint` over its other mutable fields (name, remarks, linked-to entity, aka names, IMO, MMSI, other IDs, call sign, type, flag, tonnage, owner). This split is what lets `event_type` distinguish a genuine program change from an unrelated data update.

**Domain-specific `event_type` vocabulary — not the fleet's generic `NEW_LISTING`/`CLOSED` pattern.** Per `dataset_schema.json` and `src/delta.ts`, this actor's real event types are: **`SANCTION`** (first time this vessel has been seen — kept as `SANCTION`, not a generic "listing," because an OFAC SDN designation genuinely is a sanction action), **`STATUS_CHANGE`** (the vessel's sanctions program(s) changed since it was last seen), **`UPDATED`** (some other tracked field changed but programs didn't), **`SNAPSHOT_NO_DIFF`** (identical to last time — only ever delivered when `onlyNew` is off), and **`DELISTED`** (a previously-seen vessel is absent from the current OFAC feed). There is no `CLOSED` event in this actor at all — a sanctions delisting and a tender closing are different real-world events, so this actor does not reuse the fleet's generic vocabulary where it doesn't fit.

**`DELISTED` is a trustworthy signal here because the source is a complete census.** The OFAC SDN.XML feed is always fetched and parsed as one complete, unpaginated file (confirmed live: 19,329 total SDN entries), so a previously-seen `uid` genuinely absent from a fresh fetch is a real delisting, not just "not linked from this particular run" the way a paginated or query-narrowed source would be ambiguous about. That guarantee is gated on `truncatedByMaxItems` being false in `src/fetchVesselRecords.ts`: `maxItems` caps how many records this run *delivers*, never how much of the underlying OFAC feed is read, but the walk that records "this uid was seen this run" runs inside the same loop as delivery — so once `maxItems` triggers a break, later entries are never visited either, and `DELISTED` detection is skipped for that run rather than risk a false positive (logged when it happens). `DELISTED` records also carry fewer fields than a normal record by design: `record_id`, `event_type`, `uid`, `vesselName`, `imoNumber`, `scraped_at`, `is_new` (always `false`), `source_url`, and `lastConfirmedListedAt` — a delisted vessel's programs, flag, owner, and other native fields are honestly left absent rather than backfilled with stale last-known values.

**What `onlyNew` actually does**, per this actor's own `input_schema.json`: *"When enabled, persists a content fingerprint per vessel (uid) between runs in this actor's own key-value store and returns only records that are new since the last run OR whose sanctions program(s) or other tracked fields changed since they were last seen — records identical to last time are skipped. Vessels no longer present in the current OFAC feed are always reported as DELISTED regardless of this setting (when the run was not itself truncated by maxItems...). Recommended for recurring monitoring; leave off for a full extraction of the current vessel-type SDN list."* Concretely, this is a **disclosed v2 behavior upgrade**: `onlyNew` now means "new or changed," delivering `STATUS_CHANGE`/`UPDATED` records too, not just first-ever sightings (per `CHANGELOG.md` 2.0.0) — a vessel's sanctions program changing is exactly the kind of thing a recurring compliance monitor should surface, not silently suppress just because the vessel itself was seen before.

**Internal 18-field Unified Master Schema (UMS), separate from the public dataset shape.** `src/schemas.ts` defines a `UnifiedRecordSchema` — a fixed 18-field contract (`record_id`, `event_type`, `scraped_at`, `is_new`, `source_url`, `recipient_or_defendant_name`, `entity_identifier_native`, `value_native`, `value_currency`, `value_usd_normalized`, `effective_date_iso`, `publish_date_iso`, `category_or_type`, `status_or_estado`, `awarding_or_regulating_agency`, `jurisdiction`, `source_document_url`, `reference_number`) used to normalize every record for the fleet's shared cross-actor entity graph. Every pushed record is validated against this UMS contract as a non-blocking correctness check (a failure is logged loudly, not silently swallowed, per `main.ts`) — but the UMS envelope is **not** what gets pushed to this actor's own Apify dataset. The dataset item is the richer, native OFAC/UN field set documented below; the UMS is an internal normalization adapter (`src/umsNormalizer.ts`), matching the convention used across this fleet's other actors.

**UN cross-reference is free-text matching, not a structured join.** Because the UN Consolidated List carries no dedicated vessel record type, `crossReferencedInUnConsolidatedList` is computed by regex-matching an `"IMO Number: NNNNNNN"` pattern inside UN entity/individual designation text (`src/unConsolidatedList.ts`) — a genuine, documented corroboration signal, not a fabricated structured UN vessel record.

### Input Schema & JSON Configuration Example

| Field | Type | Default | Description |
| --- | --- | --- | --- |
| `maxItems` | integer (min `1`) | `250` | "Hard cap on how many vessel-type SDN records to return this run, taken in the order OFAC lists them in the source feed." |
| `onlyNew` | boolean | `false` | "When enabled, persists a content fingerprint per vessel (uid) between runs in this actor's own key-value store and returns only records that are new since the last run OR whose sanctions program(s) or other tracked fields changed since they were last seen - records identical to last time are skipped. Vessels no longer present in the current OFAC feed are always reported as DELISTED regardless of this setting (when the run was not itself truncated by maxItems - see the DELISTED section of README.md). Recommended for recurring monitoring; leave off for a full extraction of the current vessel-type SDN list." |
| `enrichWithUnConsolidatedList` | boolean | `true` | "When enabled (default), additionally fetches the UN Security Council Consolidated Sanctions List and flags OFAC vessel records whose IMO number is also mentioned in a UN entity's designation text. Adds one extra live fetch and a linear scan of the UN list per run; disable for a faster OFAC-only run." |
| `programFilter` | array of strings (stringList editor) | *(none — all programs)* | "Optional: only return vessels whose Program list contains at least one of these OFAC program codes (case-insensitive substring match, e.g. "IRAN", "DPRK2", "RUSSIA-EO14024"). Leave empty to return vessels from all programs." |
| `vesselNameContains` | string (textfield editor) | *(none)* | "Optional case-insensitive substring filter on the vessel's listed name, applied before maxItems. Useful for a narrow monitoring run against one vessel of interest." |

A full recurring-monitor configuration, valid against `input_schema.json`:

```json
{
  "maxItems": 100,
  "onlyNew": true,
  "enrichWithUnConsolidatedList": true,
  "programFilter": ["IRAN", "DPRK2"],
  "vesselNameContains": "ARTAVIL"
}
```

A minimal one-off full extraction (all defaults):

```json
{
  "maxItems": 250,
  "onlyNew": false,
  "enrichWithUnConsolidatedList": true
}
```

### Output Dataset Sample & Data Dictionary

> **A note on the identifier field.** `dataset_schema.json` documents this field under the label `ofacUid`, but the actor's deployed extraction code (`src/types.ts`, `src/parseSdnXml.ts`) and the actor's own README output example both actually emit it as **`uid`** — that is the field name a real API response returns, and it's what the table and JSON example below use, so this documentation matches what you'll actually receive.

| Field | Type | Description |
| --- | --- | --- |
| `uid` | string | OFAC's own stable internal identifier for this SDN entry (the `<uid>` element / CSV `ent_num` column). Stable across list republications. |
| `vesselName` | string | The vessel's listed name on the OFAC SDN List. |
| `sdnType` | string | Always `"Vessel"` — this actor filters the SDN list to this type only. |
| `programs` | array of strings | OFAC program code(s) this designation falls under, e.g. `IRAN`, `DPRK2`. |
| `remarks` | string | null | OFAC's free-text remarks field for this entry — the source text `linkedTo` is extracted from. |
| `linkedTo` | string | null | Best-effort extraction of a `"Linked To: X"` clause from `remarks`, e.g. the vessel's designated owning/operating entity. |
| `akaNames` | array of objects | `{ type, category, name }` — Also Known As entries (`type`: a.k.a. or f.k.a.; `category`: strong or weak). |
| `imoNumber` | string | null | 7-digit IMO ship identification number, extracted from the id-list entry whose `idType` is `"Vessel Registration Identification"`. Null when OFAC has not recorded one for this vessel — a real, documented gap; not every SDN vessel entry carries an IMO. |
| `mmsi` | string | null | Maritime Mobile Service Identity number, when the `idList` carries an entry with `idType` `"MMSI"`. |
| `otherIds` | array of objects | `{ idType, idNumber }` — remaining `<id>` entries not consumed as `imoNumber`/`mmsi` (e.g. Former Vessel Flag, Additional Sanctions Information). |
| `callSign` | string | null | Vessel radio call sign, from `vesselInfo`. |
| `vesselType` | string | null | Vessel type, from `vesselInfo` (e.g. Crude Oil Tanker). |
| `vesselFlag` | string | null | Flag state, from `vesselInfo`. |
| `tonnage` | string | null | Tonnage, from `vesselInfo`. |
| `grossRegisteredTonnage` | string | null | Gross registered tonnage, from `vesselInfo`. |
| `vesselOwner` | string | null | Vessel owner, from `vesselInfo`. |
| `listPublishDateRaw` | string | The `<Publish_Date>` of the SDN list snapshot this record was read from (`MM/DD/YYYY`) — one value shared by every entry from the same run's fetch, since OFAC's feed carries no per-entry designation date. |
| `crossReferencedInUnConsolidatedList` | boolean | `true` when this vessel's IMO number was also found (via free-text `"IMO Number: NNNNNNN"` extraction) in the UN Security Council Consolidated Sanctions List. Always `false` when `enrichWithUnConsolidatedList` was disabled, or when the vessel has no `imoNumber` to match on. |
| `unConsolidatedListMatches` | array of objects | `{ dataId, name, referenceNumber, listedOn }` — the matching UN entity/individual record(s), populated only when `crossReferencedInUnConsolidatedList` is `true`. |
| `record_id` | string | `OFAC-SDN-<uid>` — stable across runs. |
| `event_type` | string | `SANCTION` on first sighting of a vessel. `STATUS_CHANGE` if its sanctions program(s) changed since it was last seen. `UPDATED` if some other tracked field changed. `SNAPSHOT_NO_DIFF` if identical to last time (only ever delivered when `onlyNew=false`). `DELISTED` if a previously-seen vessel is no longer in the current OFAC feed (only computed when the run was a complete, untruncated census). |
| `scraped_at` | string | ISO-8601 timestamp of this extraction. |
| `is_new` | boolean | `true` if not seen in a prior run (delta mode, `onlyNew` input). |
| `source_url` | string | Per-vessel permalink on `sanctionssearch.ofac.treas.gov` (OFAC's own public Sanctions List Search tool), e.g. `https://sanctionssearch.ofac.treas.gov/Details.aspx?id=15036`. |

A realistic dataset record for a normal (non-delisted) event — illustrative values, every field name drawn directly from the actor's real code and schema:

```json
{
  "uid": "15036",
  "vesselName": "ARTAVIL",
  "sdnType": "Vessel",
  "programs": ["IRAN"],
  "remarks": "Vessel Registration Identification IMO 9187629; Linked To: NATIONAL IRANIAN TANKER COMPANY.",
  "linkedTo": "NATIONAL IRANIAN TANKER COMPANY",
  "akaNames": [
    { "type": "a.k.a.", "category": "strong", "name": "ARTA" }
  ],
  "imoNumber": "9187629",
  "mmsi": "422123456",
  "otherIds": [
    { "idType": "Former Vessel Flag", "idNumber": "Panama" }
  ],
  "callSign": "EQFY",
  "vesselType": "Crude Oil Tanker",
  "vesselFlag": "Iran",
  "tonnage": "159939",
  "grossRegisteredTonnage": "160000",
  "vesselOwner": "NATIONAL IRANIAN TANKER COMPANY",
  "listPublishDateRaw": "09/05/2026",
  "crossReferencedInUnConsolidatedList": true,
  "unConsolidatedListMatches": [
    { "dataId": "QDi.123", "name": "NATIONAL IRANIAN TANKER COMPANY", "referenceNumber": "IRAN-3", "listedOn": "2012-07-31" }
  ],
  "record_id": "OFAC-SDN-15036",
  "event_type": "SANCTION",
  "scraped_at": "2026-09-08T14:00:00.000Z",
  "is_new": true,
  "source_url": "https://sanctionssearch.ofac.treas.gov/Details.aspx?id=15036"
}
```

A `DELISTED` record uses a deliberately smaller field set — no stale native fields are carried forward:

```json
{
  "record_id": "OFAC-SDN-14812",
  "event_type": "DELISTED",
  "uid": "14812",
  "vesselName": "SEA GLORY",
  "imoNumber": "9345671",
  "scraped_at": "2026-09-08T14:00:00.000Z",
  "is_new": false,
  "source_url": "https://sanctionssearch.ofac.treas.gov/Details.aspx?id=14812",
  "lastConfirmedListedAt": "2026-08-11T14:00:00.000Z"
}
```

### Multi-language Integration Snippets

**cURL**

```bash
curl "https://api.apify.com/v2/acts/stefano_seggio~actor-19-maritime-sanctions-monitor/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "maxItems": 250,
        "onlyNew": true,
        "enrichWithUnConsolidatedList": true,
        "programFilter": ["IRAN", "DPRK2"]
      }'
```

**Python (`apify-client`)**

```python
import os
from apify_client import ApifyClient

client = ApifyClient(os.environ["APIFY_TOKEN"])

run = client.actor("stefano_seggio/actor-19-maritime-sanctions-monitor").call(
    run_input={
        "maxItems": 250,
        "onlyNew": True,
        "enrichWithUnConsolidatedList": True,
        "programFilter": ["IRAN", "DPRK2"],
    }
)

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(item["uid"], item["event_type"], item["vesselName"], item.get("imoNumber"))
```

**Node.js (`apify-client`)**

```javascript
import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: process.env.APIFY_TOKEN });

const run = await client.actor('stefano_seggio/actor-19-maritime-sanctions-monitor').call({
    maxItems: 250,
    onlyNew: true,
    enrichWithUnConsolidatedList: true,
    programFilter: ['IRAN', 'DPRK2'],
});

const { items } = await client.dataset(run.defaultDatasetId).listItems();
for (const item of items) {
    console.log(item.uid, item.event_type, item.vesselName, item.imoNumber);
}
```

### Pricing Model Explanation

This actor bills per event ("pay-per-event"), with platform usage included in the event price — there is no separate compute charge on top.

| Event | Price | When it fires on this actor |
| --- | --- | --- |
| `result` | **$0.0005** per record | Every dataset item this run delivers — a `SANCTION`, `STATUS_CHANGE`, `UPDATED`, or `SNAPSHOT_NO_DIFF` record from the live OFAC feed, and equally a synthesized `DELISTED` record from persisted state. |
| `apify-actor-start` | **$0.00005** | Once per run, when the run starts. |

Unlike some other actors in this fleet, **there is only one billed tier here — no cheaper "listing" vs. pricier "detail" split.** Per this actor's own `CHANGELOG.md` (2.0.0, "Not added and why"): *"No pricing/monetization change. The live-configured single-tier `result` price ($0.0005/record) was already correct and is untouched — below the fleet's $0.003 rate card, a defensible independent choice for a simpler-per-record domain than a full tender detail page."* That single flat rate reflects the source reality: both the OFAC SDN.XML feed and the UN Consolidated List XML feed are single-file, plain unauthenticated downloads with no per-record fetch cost and no proxy requirement, so there is no "extra work per record" for a two-tier split to price differently — every record, whether newly sanctioned, reclassified, or delisted, costs this actor the same amount of work to produce and is billed the same $0.0005.

**On `onlyNew` and unchanged records:** when `onlyNew: true`, a vessel classified `SNAPSHOT_NO_DIFF` (identical fingerprint to its last-seen state) is skipped by a `continue` in `src/fetchVesselRecords.ts` *before* `Actor.pushData()` or `Actor.charge()` ever run for it. It is never delivered to the dataset and never billed — not billed at $0, simply never created as a chargeable event in the first place. `DELISTED` records are the one exception that is always billed regardless of `onlyNew`, since a delisting is inherently new, actionable information for a compliance monitor and is never suppressed as "unchanged." Concretely: a scheduled `onlyNew` run against the full ~1,540-vessel register that finds, say, 3 newly sanctioned vessels, 2 program changes, and 1 delisting costs 6 × $0.0005 = **$0.003** plus the $0.00005 run-start charge — you pay only for the handful of records that actually changed, not for re-delivering the unchanged majority of the list every run.

# Actor input Schema

## `maxItems` (type: `integer`):

Hard cap on how many vessel-type SDN records to return this run, taken in the order OFAC lists them in the source feed.

## `onlyNew` (type: `boolean`):

When enabled, persists a content fingerprint per vessel (uid) between runs in this actor's own key-value store and returns only records that are new since the last run OR whose sanctions program(s) or other tracked fields changed since they were last seen - records identical to last time are skipped. Vessels no longer present in the current OFAC feed are always reported as DELISTED regardless of this setting (when the run was not itself truncated by maxItems - see the DELISTED section of README.md). Recommended for recurring monitoring; leave off for a full extraction of the current vessel-type SDN list.

## `enrichWithUnConsolidatedList` (type: `boolean`):

When enabled (default), additionally fetches the UN Security Council Consolidated Sanctions List and flags OFAC vessel records whose IMO number is also mentioned in a UN entity's designation text. Adds one extra live fetch and a linear scan of the UN list per run; disable for a faster OFAC-only run.

## `programFilter` (type: `array`):

Optional: only return vessels whose Program list contains at least one of these OFAC program codes (case-insensitive substring match, e.g. "IRAN", "DPRK2", "RUSSIA-EO14024"). Leave empty to return vessels from all programs.

## `vesselNameContains` (type: `string`):

Optional case-insensitive substring filter on the vessel's listed name, applied before maxItems. Useful for a narrow monitoring run against one vessel of interest.

## Actor input object example

```json
{
  "maxItems": 250,
  "onlyNew": false,
  "enrichWithUnConsolidatedList": true
}
```

# Actor output Schema

## `results` (type: `string`):

No description

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {};

// Run the Actor and wait for it to finish
const run = await client.actor("stefano_seggio/actor-19-maritime-sanctions-monitor").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {}

# Run the Actor and wait for it to finish
run = client.actor("stefano_seggio/actor-19-maritime-sanctions-monitor").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{}' |
apify call stefano_seggio/actor-19-maritime-sanctions-monitor --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,stefano_seggio/actor-19-maritime-sanctions-monitor"
        }
    }
}

```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/dR68wHyuOLS2WEhmo/builds/yyBW91Ushb2rIdjo7/openapi.json