Skip to main content
This is a private API and requires secure connection with ERP software!
Transport: AMQP (pub/sub). The platform publishes notifications to broker queues.

Message Envelope (Common)

Notifications are published as domain payloads (no extra wrapper) to the queues listed below.
  • Content-Type: application/json
  • Delivery: at-least-once (consumer should ack after successful processing)
  • Idempotency hint: use the top-level id and event-specific keys to de‑duplicate if your consumer is retried.

1) Customer Change Push Notification

Emitted when a customer is created/updated/deactivated in ERP.
Queue: secom-customer-queue

Notes

  • id corresponds to customerId in the ERP.
  • status can be Active or Passive.

Example Payload (with address/contact fields)

The object MAY include additional customer attributes and arrays (e.g., addresses, contacts) depending on ERP mapping. Treat unknown properties as forward‑compatible.

2) Subscription Change Push Notification

Emitted when a subscription/agreement changes state or details in ERP.
Queue: secom-subscriptions-queue

Notes

  • id corresponds to subscriptionId in the ERP.
  • engagedParty corresponds to customerId in the ERP.

Example Payload (with ERP property bag)

Schema variance: The ERP may send additional key/value tuples inside properties (triplets of name, valueType, value). Consumers should parse this bag defensively.

Consumer Guidance

  • Ack/Nack: use your AMQP client’s normal ack flow; only ack after persisting/processing.
  • Retries: if your app crashes before ack, the message will be re‑delivered. Make handlers idempotent.
  • Ordering: do not rely on strict global ordering across queues.