Webhook Events and JSON Payload

A Workflow webhook sends an event notification when a configured iXpole action occurs. The notification identifies the changed object and provides paths for retrieving its details. This article describes the outgoing webhooks configured in Admin >> Workflow >> Webhooks; incoming webhooks from integration partners have their own contracts.

In this article you will learn which webhook events are available and what JSON iXpole sends

Available webhook events

In Admin >> Workflow >> Webhooks, the Action list offers the following object and action combinations. The action names below are the exact values used in the JSON action field. A webhook runs only when it is active, its object and action match, and its optional filter returns true.

Object in the Action list	Available actions
Customers	`Add`, `Update`, `Delete`, `Activate`, `Deactivate`
CustomerContacts	`Add`, `Update`, `Delete`
CustomerAddresses	`Add`, `Update`, `Delete`
Sales	`SaveAsFinal`, `Cancelled`, `OnlineOrder`, `OnlineOrderUpsellItem`, `InvoicePaid`, `eSignAccept`, `eSignDecline`, `Delete`, `PendingOrder`, `Update`
Events	`Add`, `Update`, `Delete`, `OpenDownload`, `CloseDownload`, `Deactivate`
Products	`Add`, `Update`, `Delete`
OnDemandSales	`Add`, `Delete`
Packages	`Add`, `Update`, `Delete`
Formulas	`Add`, `Update`, `Delete`
Tickets	`Add`, `Update`, `Delete`, `Downloaded`, `Scanned`, `SentToApp`

OnlineOrderUpsellItem applies to an online order with at least one upsell item. PendingOrder means an order requiring approval. OpenDownload and CloseDownload refer to opening or closing ticket downloads for an event. Deactivate for Events refers to deactivation for new sales. Packages and Formulas are hospitality objects.

Webhook Action list

JSON sent to the endpoint

When a webhook has a URL in its Task field, iXpole sends an HTTP POST to that URL with Content-Type: application/json;charset=UTF-8. The body contains event metadata, not the complete customer, sale, ticket, or other object. This is an illustrative Customers / Add message using the current v2 payload shape:

{
  "tenant": "00000000-0000-0000-0000-000000000000",
  "object": "Accounts",
  "objectId": 123,
  "objectUuid": null,
  "action": "Add",
  "actionBy": "demo.user",
  "actionOn": "2026-10-08T12:34:56Z",
  "baseUrl": "https://example.ixpole.com/",
  "objectPath": "crm/accounts/details?customerId=123",
  "apiPath": "api/accounts/123"
}

The values above are examples. The payload fields are:

Field	Meaning
`tenant`	iXpole installation UUID.
`object`	Object type. In v2, `Customers` becomes `Accounts`, `CustomerContacts` becomes `Contacts`, and `CustomerAddresses` becomes `Addresses`. Other option names remain unchanged.
`objectId`	Numeric ID of the affected object.
`objectUuid`	Object UUID when the action supplies one; otherwise it can be `null`.
`action`	Exact action name from the table above.
`actionBy`	User name associated with the action.
`actionOn`	UTC time when the webhook payload is built.
`baseUrl`	Base URL of the iXpole installation.
`objectPath`	Relative iXpole page path for the object, when mapped.
`apiPath`	Relative API path for retrieving the object, when mapped.

Combine baseUrl with apiPath to retrieve the current object through the API with suitable authorization. The objectPath is a navigation path, not an API response. For deleted objects, a later API lookup may no longer return the object.

Configure and test delivery

Open Admin >> Workflow >> Webhooks and choose the Action that matches the event you need.
Enter the receiving URL in Task, choose Version, and save the active webhook. Add a Filter only if some matching objects should be excluded.
Trigger the action with a safe test record and inspect the request received by your endpoint.
Use the Workflow Log shortcut to investigate delivery errors. The receiving endpoint should handle repeated notifications safely and fetch object details from the API when it needs them.

If no URL is configured, the same payload is sent to the tenant's service-bus destination instead of an HTTP endpoint.

Note The UI offers `v1` and `v2`, but the current production payload builder returns the v2 object even when `v1` is selected. Build new receivers for the v2 fields shown above and verify an existing v1 integration before changing it.

Knowledge Base