Event

trigger.wise_event

TriggerBusiness appsconnection requiredruns in-engine

Creates one Wise subscription per event type on the tenant's profile at publish and starts one run per notification, verified against Wise's RSA signature.

Start a run when Wise sends a notification (transfer state change, balance update, refund…).

Ask about Wise All Wise nodes Provider API docs ↗

Connection

Required: Yes — the node will not save without one
Auth type: Bearer token
Providers: Wise
Secret shape: the Wise API token, or {"api_token": "…"}
Config it needs: base_url, api_version, profile_id
Resolved by: config.connection_id, else node.connection_id
Note: The connection needs a profile_id (here or on the node) — Wise keys profile-level subscriptions on it. base_url picks production or sandbox, and each environment signs with its own key. Publishing also needs MANTLE_APP_PUBLIC_BASE_URL set to an https URL with no port and no query string: Wise refuses anything else as a callback.

Configuration

3 fields, none required. A dotted path is a nested object and name[] an array of objects — the editor renders the same tree.

Field	Type	Required	Default	Constraints	Example
events Which Wise events to subscribe to. One subscription is created per event type and deleted again when the workflow is unpublished or disabled. Only Wise's profile-level events are offered — the rest need a partner client key this connection does not carry.	array	No	["transfers#state-change"]	1–11 characters; array of string	—
schema_version Payload schema version to subscribe with. Leave at 4.0.0 unless a workflow was written against an older shape; 4.0.0 and later are the versions with millisecond timestamps, which is what makes events orderable.	string	No	4.0.0	matches ^\d+\.\d+\.\d+$	—
profile_id Subscribe on this Wise profile instead of the one on the connection. Most accounts own a personal and a business profile.	string	No	—	—	—

Example configuration

Every value below is the contract’s own example or default — nothing invented.

{
  "events": [
    "transfers#state-change"
  ],
  "schema_version": "4.0.0"
}

Output

One shape.

wise notification

The flattened Wise notification. `data`'s own keys vary by event_type, so the shape is open below the declared fields.

Extra keys beyond the ones listed can appear.

Field	Type	Example
event_type The Wise event type, e.g. transfers#state-change. Branch on this when the trigger subscribes to more than one.	string	transfers#state-change
subscription_id The Wise subscription that produced this notification.	string	01234567-89ab-cdef-0123-456789abcdef
schema_version The payload schema version the subscription was created with. 4.0.0 and later carry millisecond-precision timestamps.	string	4.0.0
sent_at When Wise sent this notification. Not an event identity: a retry of the same event carries a later sent_at.	string	—
occurred_at When the thing actually happened, from Wise's data object. This is the timestamp to order events by.	string	—
resource_id Id of the resource the event is about — the transfer, balance account, recipient — as a string, so a 64-bit id survives JSON.	string	49983981
resource_type That resource's Wise type, e.g. transfer or balance-account.	string	transfer
profile_id The Wise profile the resource belongs to, where the event carries one.	string	16055450
current_state The state the resource moved to. Read from current_state, or to_status on the events that name it that way. Empty on events with no state.	string	outgoing_payment_sent
previous_state The state it moved from, or empty when this is the first state.	string	processing
delivery_id Wise's X-Delivery-Id. A UUID per delivery attempt — useful in a support ticket, but not the idempotency key, because a retry gets a new one.	string	a1b2c3d4-e5f6-7890-abcd-ef1234567890
test True when Wise sent this to prove the callback works rather than because something happened. Test payloads carry placeholder ids, so check this before anything that moves money.	boolean	false
data Wise's data object — the event-specific half. Its keys depend on event_type, which is why this shape is open.	object	—
payload The notification envelope exactly as Wise sent it, for anything the fields above do not lift out.	object	—

{
  "current_state": "outgoing_payment_sent",
  "data": {
    "current_state": "outgoing_payment_sent",
    "occurred_at": "2026-09-08T12:34:56.789Z",
    "previous_state": "processing",
    "resource": {
      "account_id": 14124090,
      "id": 49983981,
      "profile_id": 16055450,
      "type": "transfer"
    }
  },
  "delivery_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "event_type": "transfers#state-change",
  "occurred_at": "2026-09-08T12:34:56.789Z",
  "payload": {
    "event_type": "transfers#state-change",
    "schema_version": "4.0.0"
  },
  "previous_state": "processing",
  "profile_id": "16055450",
  "resource_id": "49983981",
  "resource_type": "transfer",
  "schema_version": "4.0.0",
  "sent_at": "2026-09-08T12:34:56.123Z",
  "subscription_id": "01234567-89ab-cdef-0123-456789abcdef",
  "test": false
}

Notes

Wise issues no shared secret. Deliveries are verified against Wise's own published RSA public key (X-Signature-SHA256 over the raw body); an unsigned or mis-signed POST is refused with 401.
One run per event. The idempotency key is built from Wise's own event identity (subscription, event type, resource and occurred_at) because X-Delivery-Id changes on every retry — and Wise retries up to 25 times over two weeks.
Creating a subscription makes Wise send a test notification immediately; that one is answered during provisioning and starts no run. A test notification sent later does start a run, with `test` set true.
The subscriptions are deleted at Wise when the workflow is unpublished, disabled or archived. Events already in flight are still delivered.

Related Wise nodes

See Event run in a workflow.

In a technical demo we add the Wise connection, drop the node on the canvas and let Workflow Health pre-flight it before the first real run.

Book a technical demo Talk to sales