Additional Screening Checks
Wait for the screening to finish
screening_status has moved from "PENDING" to OK, WARNING or CRITICAL. Screening a Vessel covers the polling.How to call them
screenresult parameter, the id read from the screen_results array of GET /transaction. Positional discrepancy is the exception and filters on transaction_id instead.meta and objects envelope and accepts limit and offset for pagination.| Endpoint | Filters on | Feature gate |
|---|---|---|
GET /flaghistorycheck | screenresult | None |
GET /companyhistorycheck | screenresult | None |
GET /ship-status | screenresult | None |
GET /stspairing | screenresult | STS_PAIRING |
GET /otherassociations | screenresult, required | PANDI_CLUB_SCREENING |
GET /positionaldiscrepancy | transaction_id | Per event_type |
A new response header on these endpoints
200 response now also carries a Terms-and-Conditions-of-API-Use header pointing at the PurpleTRAC terms of service.History checks
most_recent flag. Set it to true to get only the latest records for the matched screen result, which is what you want after a rescreening.Flag history
GET /flaghistorycheck reports how the vessel's flag has changed, with a flag_changes_count and the calculated history_severity.Company history
GET /companyhistorycheck reports how the companies around the vessel have changed: registered owner, operator, ship manager, technical manager and group beneficial owner. Each record covers one association_role, with a company_changes_count and its own history_severity.Ship status
GET /ship-status reports the operational status of the vessel at the moment it was screened, "Broken Up" or "Laid Up" for example, along with the severity that status carries.This response is shaped differently
ship-status returns id, status and severity only. It omits resource_uri, screenresult and creation_date, which most other endpoints on this page return. The path also uses a hyphen where the others use none.Ship-to-ship pairing
GET /stspairing returns the vessels that came alongside the screened vessel: where and when the pairing happened, how long it lasted, and any high-risk zones it matched.STS pairing is gated on a feature flag
STS_PAIRING enabled on your account. Without it you get 404 Not Found whatever data exists behind it. Ask your Pole Star representative if you expect pairings and see a 404.P&I club
GET /otherassociations returns the P&I club the vessel is associated with, the severity that carries, and any sanctions matched against the club itself. An unidentified club comes back as "Unknown".pandi_club path. The data is served from /otherassociations, which is built to carry other kinds of association later and currently returns P&I club records only.Two conditions gate this data, and neither returns an error
PANDI_CLUB_SCREENING enabled, and the transaction has to have opted in with "pandi_club": true on the POST /registration call. Miss either and you get a normal 200 OK with an empty objects list, not the 404 that the STS pairing gate returns. screenresult is required here, and omitting it returns 400 Bad Request.Positional discrepancy
GET /positionaldiscrepancy returns AIS spoofing events detected on a transaction: two vessels reporting the same position, box-shaped or circular movement patterns, MMSI outliers. Each event names the zones and ports involved at its start and stop.transaction_id, an exact match, and takes order_by on start_timestamp or stop_timestamp, defaulting to -start_timestamp.event_type on the account, so an empty response can mean the pattern was not detected or that the detection for it is switched off. Confirm which with your Pole Star representative before reading anything into a quiet result.Related
Modified at 2026-10-01 09:42:21