Skip to main content
The API is versioned in the path (/api/v2/). Additive changes (new endpoints, new optional response fields) are not breaking. Removing a field, changing a type, or tightening a scope is breaking and ships under a new path version.

​
2026-09-22 — item-sized scopes

Five new scopes, each filtering one block within a response your key already reads. Every existing tier that could already see a block keeps seeing it — these scopes were added to management, recruiter and vessel automatically, so no partner on those tiers loses anything. An external partner’s per-contract scopes are unaffected unless CrewPass adds these to your contract — in particular, crew:profile:read alone no longer implies the contact or professional block for a scope_overrides-based partner that hasn’t been upgraded (it always has for management / recruiter / vessel). Profile (GET /api/v2/employers/me/crew/{id}/profile)
  • crew:contact:read (new): gates email, phone, country_code.
  • crew:professional:read (new): gates nationality, languages, skills, years_experience, bio and profile_photo_url — this is the old base profile in full, minus name / rank and the contact fields above.
  • crew:experience:read (new): gates employment_history only.
  • crew:personal:read (new): gates date_of_birth, address, passport and visas.
  • crew:profile:full:read still works exactly as before — it’s now a compatibility alias for crew:experience:read + crew:personal:read together (unchanged: it never included the professional-block fields above).
  • Only name and rank need nothing beyond crew:profile:read.
Photo (GET /api/v2/employers/me/crew/{id}/photo) — Behaviour change: now also needs crew:professional:read (the photo is part of the professional block), on top of the existing crew:profile:read gate. Documents (GET /api/v2/employers/me/crew/{id}/documents and its download endpoint) — Behaviour change: a document whose classification.document_class is medical now needs the new crew:medical:read scope; otherwise it’s left out of the list and its download link 404s. Compliance (POST /api/v2/employers/me/crew/{id}/compliance-checks) — Behaviour change: a medical requirement row’s satisfied_by document details now need crew:medical:read too. The row’s status and group are never hidden. Two scopes, connections:read and connections:write, are declared for a future surface and are not granted to any tier yet.

​
2026-09-22 — webhooks: crew who join your fleet

No change to any payload or field.
  • Crew who join your fleet arrive in full. When a crew member is added to one of your vessels, you receive a crew.document.processed for each document they already hold, plus their current compliance, status and profile. Registering an endpoint still sends no backlog.
  • Update events carry a change. crew.document.updated, crew.compliance.changed and crew.status.changed are sent only when a value in their payload changes, so a recalculation that leaves every figure the same sends nothing. See Webhooks.

​
2026-09-18 — webhook delivery, stated plainly

No change to any payload or field. This writes down how delivery behaves, so you can build a receiver against it:
  • Changes reach you within about 15 minutes. CrewPass checks your fleet on a schedule rather than at the instant of a write.
  • Registering an endpoint does not send you a backlog. Read the current state through the API once; webhooks keep you in step from there.
  • Events are not ordered. Each one says how something looks now.
  • crew.document.updated covers any visible change to a document you already have, not only a change of verification status.
  • There is no “document removed” event. See Webhooks.

​
2026-09-17 — document classification and vessel IMO numbers

Documents now tell you what they are, as codes you can map to your own document types, so you no longer need to work it out from the title. Every change is additive except the two marked Behaviour change and Value change. Documents (GET /api/v2/employers/me/crew/{id}/documents and the crew.document.* webhooks)
  • classification (new): what the document is. It gives the document_class, the category_code, the CrewPass certificate type it was matched to (catalogue_title, with a stable id), stcw_regulation and stcw_codes, level, is_refresher, flag_state, coc_capacities, and the sources it was built from. See Classify documents.
  • Document codes (new page): every value a classification can contain. Each classification includes the taxonomy_version (the version of this list) it was built with.
  • review_status (new): the result of CrewPass’s review, separate from expiry.
  • is_expired and no_expiry (new): tell a document that doesn’t expire apart from one whose expiry date wasn’t recorded.
  • is_current and superseded_by (new): show when a certificate has been replaced by a newer edition.
  • Behaviour change: only documents CrewPass has finished processing are shared. Documents still being processed, and older uploads from before CrewPass’s current document processing, are no longer listed, counted in documents_expiring, or available to download. A new upload appears as soon as processing completes.
  • Value change: issuer is null when the issuing authority isn’t known, instead of a placeholder such as “Unknown”.
Fleet (GET /api/v2/employers/me/fleet)
  • vessel_imo (new): the vessel’s IMO number, so you can match vessels without relying on names. null when CrewPass doesn’t hold one.
  • Documentation correction: each crew member’s status on the vessel is returned in status (for example active or invited), as it always has been. The Crew guide previously called this field verification_status.
API reference
  • Endpoints are now grouped by task (Account, Fleet, Crew, Documents, Compliance), with clearer names and descriptions. Page addresses in the API reference have changed.

​
2026-07-02 — compliance as a unified requirement matrix

POST /api/v2/employers/me/crew/{id}/compliance-checks now returns a full requirement matrix, so you can see at a glance exactly which requirements a crew member holds, which document satisfies each, and what is still outstanding.
  • requirements[] — one row per requirement, grouped as medical, stcw, certificate, or qualification. Each row has its own status (met · expiring · expired · missing · pending), plus title, optional expiry_date, and days_until_expiry.
  • satisfied_by[] — the actual document(s) meeting each requirement, each with document_id, title, expiry_date, and a branded download_path you can fetch directly. Empty when the requirement is unmet.
  • STCW rows carry per-module detail under modules[].
  • summary — totals per status that always reconcile with requirements[].
  • overall_status with compliance_source — the verdict comes straight from the CrewPass compliance engine (live_evaluator). If the engine is briefly unavailable the response falls back to the stored projection and flags it via compliance_source, so the provenance of every verdict is explicit.
This supersedes the earlier interim compliance breakdown with a single, consistent shape.

​
2026-06-30 — richer crew profile & document detail

Several read fields now carry more detail and map more precisely to the underlying records. All changes are additive except the two field-value changes noted below.
  • Profile phone is now returned in full international (E.164) form (dial code
    • national number, e.g. +447700900000), with a new ISO country_code alongside it. Value change: phone previously returned the national number only.
  • Profile address.full_address (new) gives the composed single-line address; line1 stays null when no street was supplied.
  • Employment history source now reports the verification level of each entry — self_reported or employer_verified. Value change: it previously returned the dashboard origin (crew_dashboard / employer_dashboard).
  • Documents now return only current, live documents — rejected, replaced/deduplicated, and inactive placeholders are excluded from listings, expiring counts, and downloads, so what you see reflects what a crew member actually holds.

​
2026-06-23 — simpler read authentication (no request signing)

Reads now authenticate with just your API key as a Bearer token over TLS — request signing has been dropped from all reads, so there is nothing to sign on a GET. HMAC signing is retained only for verifying outbound webhook deliveries. See Authentication. No request or response shapes changed; only the read auth requirement is simpler.

​
2026-06 — v1 management read surface + webhooks

The v1 management-company surface: read-only plus webhooks, on top of the auth → scope → rate-limit → HMAC → isolation → consent → audit spine. Your fleet is derived from your CrewPass employer account; there is nothing to attach. Endpoints
  • GET /api/v2/partners/me — identity + granted scopes.
  • GET /api/v2/employers/me/vessels — your vessels (vessels:fleet:read).
  • GET /api/v2/employers/me/fleet — crew across your vessels, with verification + background-check status and documents-expiring counts, paginated (vessels:fleet:read + per-crew crew:status:read).
  • POST /api/v2/employers/me/crew/lookup — resolve a crew member by email (crew:status:read).
  • GET /api/v2/employers/me/crew/{id}/profile — base profile, plus an identity block under crew:profile:full:read.
  • GET /api/v2/employers/me/crew/{id}/photo — branded photo proxy (crew:profile:read).
  • GET /api/v2/employers/me/crew/{id}/documents — documents with issuer + verification status (crew:documents:read).
  • GET /api/v2/employers/me/crew/{id}/documents/{document_id}/download — short-lived, branded file link (crew:documents:download).
  • POST /api/v2/employers/me/crew/{id}/compliance-checks — compliance as a unified requirement matrix (crew:compliance:read).
Webhooks
  • crew.document.processed, crew.document.updated, crew.compliance.changed, crew.status.changed, crew.profile.updated. See Webhooks.