Event types
This page lists the events SHIPM8 raises, grouped by area. For each one you get the trigger identifier to type into the subscription and the trigger type to pick alongside it. Both have to match, or the subscription won't fire — see Create a subscription.
Reading an identifier
Most identifiers are built from three parts:
$module_object_action
- module — the part of SHIPM8 the event comes from (
invoicing,nautical,customcontent, and so on). - object — the kind of record (
invoice,visit, or the system code of one of your own objects). - action — what happened (
add,update,finalized,eta, …).
The leading character matters:
$— the event comes from inside SHIPM8.@— the event comes from outside, pushed in by an external system.
Some identifiers have only two parts, and scheduled jobs use an ID instead of a name. Those are noted below.
Invoicing
Events about invoices. The record that travels with the event is the invoice itself.
| Trigger identifier | Trigger type | Happens when |
|---|---|---|
$invoicing_invoice_add | Create | An invoice is created — by hand, by an invoice flow, or by an import. |
$invoicing_invoice_update | Update | An invoice is changed. The event also carries the list of fields that changed. |
$invoicing_invoice_delete | Delete | An invoice is deleted. |
$invoicing_invoice_cancel | Generic | An invoice is cancelled. |
$invoicing_invoice_split | Generic | An invoice is split into separate invoices. |
$invoicing_invoice_finalized | Generic | An invoice becomes final. |
$invoicing_invoice_pendingapproval | Generic | An invoice flow puts an invoice up for approval. |
$invoicing_invoice_pendingverification | Generic | An invoice flow puts an invoice up for verification. |
$invoicing_invoice_finalized is the workhorse here: it's the moment an invoice is
settled and ready to go to a bookkeeping system.
Your own records (custom data)
Events on the objects you set up yourself in Custom data. Because those objects differ per organisation, the identifiers are built from your object's system code — the short code on the object definition:
$customcontent_<system code>_<action>
So an object with system code order gives $customcontent_order_add,
$customcontent_order_update, and so on.
| Action part | Trigger type | Happens when |
|---|---|---|
_add | Create | A record of that kind is created. |
_update | Update | A record is changed. Carries the list of changed fields. |
_delete | Delete | A record is deleted. |
_detach | Delete | A record is detached from the record it was linked to. |
The inbox
Records that arrive through the inbox — waiting to be approved before they become real
records — have their own module, customcontentinbox:
$customcontentinbox_<system code>_<action>
| Action part | Trigger type | Happens when |
|---|---|---|
_add | Create | An inbox entry is created. |
_update | Update | An inbox entry is changed. |
_delete | Delete | An inbox entry is deleted. |
_approve | Generic | An inbox entry is approved and becomes a real record. |
_decline | Generic | An inbox entry is declined. |
_addshadow | Generic | A shadow copy of an inbox entry is created. |
If you're automating something about the finished record, use customcontent. Use
customcontentinbox only when the automation is about the arrival and approval of
incoming data.
Port visits and movements
Events raised while SHIPM8 keeps port-call data up to date from the port's own systems. They fire per changed value, so the identifier names the value that changed rather than an action. All of them are trigger type Generic.
For a port visit — the whole call at port:
| Trigger identifier | Happens when |
|---|---|
$nautical_visit_eta | The estimated time of arrival changes. |
$nautical_visit_ata | The actual time of arrival is set. |
$nautical_visit_etd | The estimated time of departure changes. |
$nautical_visit_atd | The actual time of departure is set. |
$nautical_visit_status | The visit's status changes. |
$nautical_visit_agent | The agent on the visit changes. |
$nautical_visit_entrypoint | The visit gets its entry point. |
$nautical_visit_exitpoint | The visit gets its exit point. |
$nautical_visit_pierin | The ship arrives at a berth. |
$nautical_visit_pieruit | The ship leaves a berth. |
$nautical_visit_lockentry | The ship enters a lock. |
$nautical_visit_lockexit | The ship leaves a lock. |
For a movement — a single leg within the visit:
| Trigger identifier | Happens when |
|---|---|
$nautical_movement_eta | The movement's estimated arrival changes. |
$nautical_movement_ata | The movement's actual arrival is set. |
$nautical_movement_etd | The movement's estimated departure changes. |
$nautical_movement_atd | The movement's actual departure is set. |
$nautical_movement_agent | The movement's agent changes. |
You can read about the underlying data in Port visits.
Arrival and departure times are corrected repeatedly in the run-up to a call, so an ETA event can fire many times for one visit. Add conditions so the automation only acts when it should — for example on the actual times rather than the estimates.
Documents (content distribution)
Events raised after SHIPM8 has produced and delivered something. Both are trigger type Generic. The event data says which template was used, which records it covered, whether it succeeded, and any error messages.
| Trigger identifier | Happens when |
|---|---|
$contentdistribution_template_distribute | A document was produced and distributed from an export template. |
$contentdistribution_notification_distribute | A notification message was produced and distributed. |
These are how you build "and afterwards, record that it was sent" — see Chaining events.
Incoming webhooks (external systems)
When a connected system pushes a change to SHIPM8, it arrives as an event with an @
prefix and only two parts:
@service_object
Trigger type is Generic. Exact Online is the service currently supported, so
identifiers look like @exactonline_salesinvoice or @exactonline_purchaseentry — the
object part is whatever object type the webhook is registered for on the Exact Online
side.
Unlike the other events, the data here is the payload the external system sent, not a SHIPM8 record. That's why webhook automations usually pair with a Content distribution export additional data or Content distribution import action — see Action types.
Setting up the webhook itself is part of the integration; see Exact Online.
Scheduled jobs
A scheduled job doesn't have a name-based identifier. Instead the job's ID — a long
code of the form 3f2a1b00-… — is the trigger identifier, and the trigger type is
Hangfire. The job runs on its schedule and hands its data to whatever subscription
carries its ID.
This is how a recurring automation is built: the job provides the when, the subscription provides the what. You'll get the ID from the job itself.
Your own chain events
Any identifier you invent on an action's Triggers tab becomes an event you can subscribe to. Give it trigger type Generic, unless you deliberately end the name in one of the words listed on Create a subscription. See Chaining events.
If the event you need isn't listed
New events are added as SHIPM8 grows, and not every change in the app raises one. If the moment you want to automate isn't in these tables, ask SHIPM8 support — sometimes there's a nearby event that works with the right conditions, and sometimes it's a small addition on our side.
The Processed trigger type exists for events whose name ends in _processed. No area
currently raises one, so you won't need it yet — it's reserved for future use.