POST per event to every endpoint of your organization that subscribes to the event type. There are 72 types. This page lists them all. Registering an endpoint, verifying the signature and the retry rules are in Receive Nozle webhooks.
Each event has its own page in the API reference under Webhook Events, with the payload schema and an example captured from Core.
The delivery
Every delivery has the same envelope.webhook_type is the event type, object_type names the key that holds the object, and organization_id is your organization:
- The object under
object_typeis the same object the REST API returns for that resource, so you can use one parser for both. A few events wrap it, for exampleinvoice.payment_dispute_lostholds{ "invoice": {...}, "provider_error": "..." }underpayment_dispute_lost. - Until January 19, 2027, payloads also carry the old, former-prefix key names beside the new keys. Read the new keys: see legacy key names. The examples on this page show the new keys only.
- Examples are captured from Core with real identifiers replaced by placeholders.
Choose the events you receive
An endpoint with noevent_types receives every type, and gets every type Nozle adds later. To receive only some, send an array when you create or update the endpoint:
nullor["*"]means every type. An empty array is rejected.- Names are trimmed and lower-cased. An unknown type is rejected with a
422invalid_typeserror. credit_note.provider_refund_failureis the former name ofcredit_note.refund_failure. It is still accepted and saved under the new name.- Respond
2xxto types you do not handle, so Nozle does not retry them.
All events
Alerts
Customers
Credit Notes
Dunning Campaigns
Event Ingestion
Features
Subscriptions and Fees
Invoices
Integrations
Quotes
Payments
Payment Receipts
Plans
Wallets and Credits
Events to know about
Sent only on some paths
fee.tax_provider_erroris reserved. You can subscribe to it, but Core has no code path that sends it today.event.erroris deprecated. Useevents.errors.invoice.add_on_addedis not a Nozle event. Earlier versions of the API reference listed it, and no endpoint can subscribe to it.customer.crm_provider_errornames the CRM inaccounting_providerandaccounting_provider_code, the keys the accounting error uses.
order.failed
Sent once when executing an order fails and the order is marked failed. The reasons are in execution_record.errors:
plan_upgrade_intent.needs_review
Sent once when a paid plan change cannot be applied: the intent goes to review and the payment is refunded. The envelope example at the top of this page is this event.
credit_note.refund_failure
Sent when refunding a credit note at the payment provider fails:
payment_request.payment_failure
Sent when a payment attempt for a payment request fails, or when its Pay link cannot be built. provider_error.error_code says why, for example payment_request_invoices_changed:
payment_request.created and payment_request.payment_status_updated
The payment request carries automatic: true for a request Core created itself for a finalized invoice it did not charge, false for one created by dunning or by hand. An automatic request is closed (succeeded, or failed when its invoice is voided) when its invoice is paid another way or settled by a credit note, and payment_request.payment_status_updated is sent. The customer and invoices fields are omitted from this example:
subscription.updated
Sent for a change to the subscription itself, for a plan change that is scheduled or canceled, and for the subscription that a plan change replaces. The customer, plan and entitlement fields are omitted from this example:
Wallet events
wallet.created, wallet.updated, wallet.terminated and wallet.depleted_ongoing_balance carry the wallet. wallet.updated is also sent when the balance changes: