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. | |
| Invoice updated | invoice.updated | Invoice status changed (e.g. to completed after payment assignment) | |
| Document archived | invoice.archived | A document has been stored in the file archive and can now be accessed via the file end point. | |
| VAT ID validated | vatId.checked | The result of a VAT ID validation during the billrun, if activated. | |
| Payment transaction created | paymentTransaction.created | A new payment transaction has been created. | |
| 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. | |
| Payment assignment processed before settlement | paymentAssignment.processed.beforeSettlement | A payment has been assigned to a transaction before settlement receiving. Payments can be assigned to a document or an order. | |
| Payment assignment reversed before settlement | paymentAssignment.reversed.beforeSettlement | An assigned payment has been reversed before the settlement was received. Payments can be assigned to a document or an order. | |
| Settlement created | settlement.created | A settlement report has been created. | |
| Open item decision | oposCaseDecision.created | An OPOS case decision has been made. (E.g. with the type discount, or uncollectable receivable) | |
| Opos case updated | OPOS_CASE_UPDATED | Opos case has been updated (e.g. due to payment assignment or open item decision) | |
| Open item decision: reversion | oposCaseDecision.reversion | An OPOS case decision has been reversed. | |
| Basware Workflow updated | basware.workflow.updated | Basware workflow has been created or status has been changed (e.g. to technical accept after business document has been delivered) | |
| Dunning issued | dunning.issued | A dunning has been created or a dunning level has been changed. | |
| Dunning archived | dunning.archived | A dunning letter has been stored in the file archive and can now be accessed via the file end point. | |
| Dunning status aggregation updated | dunningStatusAggregation.updated | The highest dunning level of a contract has been changed. | |
| Report created | report.created | A new report has been created. |