All Docs
FeaturesCalmony PayUpdated March 15, 2026

Fix: Customer Lifecycle Webhook Events Now Firing Correctly

Fix: Customer Lifecycle Webhook Events Now Firing Correctly

Version: v1.0.65
Affected area: Webhooks — Customer lifecycle events

What Was Wrong

A spec drift issue was identified against the Calmony Pay REST API Contract: all three customer lifecycle webhook events were silently dropped and never delivered to webhook consumers.

The affected events were:

EventTrigger endpointStatus before fix
customer.createdPOST /v1/customers❌ Never emitted
customer.updatedPATCH /v1/customers/:id❌ Never emitted
customer.deletedDELETE /v1/customers/:id❌ Never emitted

In each case, the route handler completed the database operation successfully but returned a response without calling emitPayEvent. This meant that any system listening for customer activity via webhooks received no signal at all — no errors, no retries, no indication that an operation had occurred.

What Changed

The fix ensures emitPayEvent is called after every successful customer mutation:

  • POST /v1/customers — emits customer.created after the customer row is inserted.
  • PATCH /v1/customers/:id — emits customer.updated after the customer record is updated.
  • DELETE /v1/customers/:id — emits customer.deleted after the customer record is soft-deleted.

All three endpoints now conform to the Calmony Pay REST API Contract.

Who Is Affected

This fix is relevant to you if any of the following apply:

  • You have webhook endpoints registered to receive customer.created, customer.updated, or customer.deleted events.
  • You built workarounds (e.g. polling /v1/customers) because webhook events were not arriving.
  • You are building an integration that depends on real-time customer lifecycle signals for downstream processing (e.g. CRM sync, provisioning, audit logging).

Action Required

No breaking changes. This is a fix to restore intended behaviour. However, depending on your integration:

  • If you built polling workarounds: You can now rely on webhooks for customer.* events and remove the workaround.
  • If you have idempotency logic: Be aware that webhook events will now start flowing for any customer mutations going forward. Events for mutations that occurred before this fix was deployed will not be retroactively emitted.
  • If you are testing webhooks: Verify your webhook handler correctly processes customer.created, customer.updated, and customer.deleted payloads.

Webhook Event Payloads

All three customer lifecycle events follow the standard Calmony Pay webhook envelope:

{
  "id": "evt_...",
  "type": "customer.created",
  "created": 1700000000,
  "data": {
    "object": {
      "id": "cus_...",
      "email": "user@example.com"
    }
  }
}

The type field will be one of:

  • customer.created
  • customer.updated
  • customer.deleted

Refer to the API Reference for full customer object schema details.