Webhooks
Configure outbound webhooks on each app to send signed JSON event payloads whenever key data changes inside Indexed PIM. Queue delivery, inspect logs, and connect the platform to external workflows in real time.
Webhook Configuration
How webhooks work in the app
Webhooks are configured per app, not as a single global switch. From an app’s settings page, users can open the webhook manager, create one or more endpoints, choose a single event per webhook, and activate or deactivate delivery as needed.
When Indexed PIM emits an entity lifecycle event such as product.updated or order.created, the webhook subscriber looks up all active webhook records for that exact event, builds a JSON payload, and dispatches delivery to the Messenger queue instead of blocking the user request.
The queued handler then performs the outbound HTTP POST, signs the payload with HMAC SHA256, and stores a webhook log containing the request payload, response payload, HTTP status, response time, and revision data when present.
What is included
Webhook CRUD per app with URL, event, and active status
Bulk activate, deactivate, and delete actions
Queued outbound delivery through the Messenger webhook transport
Per-webhook secret and `X-Webhook-Signature` header
Log viewer with payload, status code, response body, timing, and revision context
Setup flow inside Indexed PIM
The current implementation is straightforward: choose the app, register the endpoint, select one event, and let the queue deliver the payload.
Open an app that exposes webhook management
In the current UI, webhook management is surfaced from the edit sidebar of app modules such as Products, Orders, Inventory, and Pricing. Each app keeps its own webhook list and logs.
Create a webhook record
The create screen validates the target URL, requires one event name, and lets the user decide whether the webhook starts active. A unique external ID and a random secret are generated automatically when the record is created.
Wait for a matching domain event
The webhook subscriber listens to created, updated, and deleted entity events. When the event name matches the webhook record exactly, it prepares the payload and hands delivery off to the queue.
Inspect the delivery log
The logs screen is paginated per app and shows HTTP status, response time, created time, request payload, response payload, and product revision data when the event originated from product changes.
What the outbound payload contains
Payloads are assembled dynamically from the matching entity and wrapped with account, app, and webhook context.
Envelope fields
Entity section
The entity payload key is derived from the event prefix. For example, `brand.created` yields a `brand` object and `product.updated` yields a `product` object.
Serialization is reflection-based. Scalar properties are copied directly, date fields are formatted as ISO timestamps, related objects contribute IDs and external IDs when available, and array properties are skipped.
For product events, the latest product revision is added separately with action, user name, timestamp, and field-level change data.
Example shape
{
"event": "product.updated",
"timestamp": "2026-04-21T12:00:00+00:00",
"account": {
"external_id": "acc_123",
"name": "Acme"
},
"app": {
"external_id": "app_456",
"name": "Products"
},
"webhook": {
"external_id": "web_abc"
},
"product": {
"id": 42,
"externalId": "prod_789"
},
"revision": {
"action": "updated",
"user_name": "Jane Doe",
"timestamp": "2026-04-21T11:59:54+00:00",
"changes": []
}
}Available event families
The webhook controller exposes a fixed event list in the UI. Each webhook subscribes to one exact event from that list.
Catalog Events
Brand, supplier, category, product, product group, property group, property, media, and file create/update/delete events are available in the selector.
Commercial Events
Order, customer, customer group, pricing rule, payment term, currency, unit, and language lifecycle events can all be dispatched as webhook notifications.
App Events
The list also includes app-level lifecycle hooks, so external systems can react when app records themselves are created, updated, or deleted.
Current implementation note
Each webhook subscribes to one event string. If you need multiple events sent to the same URL, the current UI requires multiple webhook records pointing to that endpoint.
Security, delivery, and observability
This feature already ships with practical controls for verifying requests and debugging failures.
Signed requests
Every webhook gets its own generated secret. The outbound handler signs the raw JSON payload with HMAC SHA256 and sends it in the `X-Webhook-Signature` header.
Solution:
Consumers can recompute the signature with the shared secret and reject spoofed requests.
Asynchronous delivery
Webhook POST requests are sent from the Messenger webhook transport instead of inline with the originating user action, which keeps the application responsive.
Solution:
Heavy or slow receivers do not block the entity save flow.
Detailed logs
The log table records request payloads, response payloads, HTTP status, response time, event name, and webhook external ID for each delivery attempt.
Solution:
Teams can inspect failed payloads and compare what was sent with what the receiver returned.
Operational limitation to know
I did not find built-in retry or exponential backoff logic in the outbound message handler. Failed requests are logged with HTTP status `0` on exceptions, but the handler itself does not implement custom retry behavior.
Solution:
Treat the current system as queued delivery plus observability, not a full retry orchestration layer.
Need event-driven integrations without building a custom export layer?
Use app-level webhooks in Indexed PIM to push signed payloads into automation tools, middleware, ERP flows, or internal services as soon as business events happen.