For certain events, the Nitrobox can send a notification (via webhooks) to another system. Notifications must be activated and set up. Notifications are sent asynchronously. Notifications are used, for example, to pick up an invoice document that has just been generated and make it available to the customer, or to trigger further follow-up processes in a third-party system (e.g. an e-commerce shop).
Retry policy
If an attempt to send a notification is met with a HTTP status code 5xx we will attempt to resend the notification up to three times until successful. If your system still rejects the request the attempts will be stored in our notification log.
4xx responses will, without retry attempts, be stored in the notification log.
Notification Log
In our Webportal under Configuration, -> Global -> Notification you will find a table at the bottom with all notifications attempted to send to your system. You will also find all failed notifications here and can retry them manually.
This can also be used to resend notifications that were previously already sent successfully, in case they got lost in your system for some reason.
Authentication
NBX uses OAuth2 with client credential flow to authenticate against your configured endpoints. Our Notification Service will send the client_id and client_secret in the Basic Auth header and the trant_type=client_credential in the body with contentType application/x-www-form-urlencoded
Available Notifications
| notification | status | technical identifier | description |
|---|---|---|---|
| Customer created | customer.created | A new customer record has been created. | |
| Customer updated | customer.updated | An existing customer has been changed. | |
| Address created | address.created | A new address record has been created for a customer. | |
| Address updated | address.updated | An existing address record for a customer has been changed. | |
| Order created | order.created | A new order has been created. | |
| Order updated | order.updated | An existing order has been changed. | |
| Order canceled | order.cancelled | An existing order has been canceled. | |
| Contract created | contract.created | A new contract (subscription) has been created. | |
| Contract updated | contract.updated | An existing contract was updated. | |
| Contract renewed | contract.renewed | An existing contract has been extended by the term defined in the plan. | |
| Contract terminated | contract.terminated | An existing contract was terminated regularly. | |
| Contract canceled | contract.cancelled | An existing contract was canceled. | |
| Contract expired | contract.expired | A Contract passes their endDate. | |
| Document created | invoice.created | A document has been created in the system. This notification is independent of the (PDF) file creation and archiving, which run as an asynchronous process. | |
| Document updated | invoice.updated | An already existing document was updated. This essentially refers to meta-information or the document status. In terms of content, documents are unchangeable. | |
| Document archived | invoice.archived | A document has been stored in the file archive and can now be accessed via the file end point. | |
| Payment Intent Result | paymentintent.result | An Payment Intent was processed in conjunction with the stored Payment Service Provider. | |
| Payment assigned | paymentAssignment.processed | A payment has been assigned to a transaction. Payments can be assigned to a document or an order. | |
| Payment assignment reversed | paymentAssignment.reversed | An assigned payment has been reversed. Payments can be assigned to a document or an order. | |
| Open item decision: discount | oposCaseDecision.discount | ||
| Open item decision: other revenue | oposCaseDecision.otherRevenue | ||
| Open item decision: uncollectable receivable | oposCaseDecision.uncollectableReceivable | ||
| Open item decision: doubtful receivable | oposCaseDecision.doubtfulReceivable | ||
| Open item decision: reversion | |||
| Settlement created | settlement.created |