Important information
Notification model
The LaaS notification system only reports that a change has occurred on an entity (relevant for the partner) in BPLS systems. To obtain any further information required, including the new status when the notification reports a change of status, the partner must access the entity (by the identifier provided in the notification).
Identifier reconciliation
The notifications are sent with the identifier of the entity whose status has changed. However, when a quotation is submitted, to create a proposal, the subsequent notifications originate from the proposal (with the proposal identifier). To reconcile the proposal with the quotation, given that their identifiers are different, the partner has to query the proposal to retrieve the corresponding quotation identifier. In the future, the same identifier will be used for the quotation and the proposal, removing this issue.
Resilience
Whenever an error occurs on the call to the partner notification endpoint, an automatic replay mechanism will try to send the notification again, at most 3 times at 1 hour intervals (these values may be adjusted in the future depending on real-life conditions).
Callback endpoint signature
The endpoint registered with the API must conform to the following specification (YAML format):
paths:
/notifications:
post:
operationId: PostNotification
tags:
- Notification
description: Report an event to the partner affecting an object, by posting a request on the callback endpoint previously registered by the partner. The functional documentation details the different situations where a notification is sent to the partner, along with the affected information on the object concerned.
requestBody:
description: The notification is designed only to report an event, without any detail. For more information, the partner queries the object specified, though the appropriate API.
required: true
content:
application/json:
schema:
type: object
required:
- entity
- event
- timestamp
properties:
entity:
type: string
description: LaaS entity sending the notification. Each possible value designates the corresponding API in the LaaS API set.
enum:
- QUOTATION
- CUSTOMER
- PROPOSAL
- PREPARED_CONTRACT
- SIGNATURE
- CONTRACT
example: QUOTATION
id:
type: string
description: Identifier of the object sending the notification, in the referential of the entity (e.g. a quotation id for a QUOTATION entity or proposal id for a PROPOSAL entity)
example: "0123456789"
event:
type: string
description: Event type, may be needed in the future for entities that could generate notifications for different functional concerns.<br >STATUS_CHANGE may be reported on QUOTATION (expired), PROPOSAL (expired, cancelled, decision reached), PREPARED_CONTRACT (expired, cancelled), SIGNATURE (initiated, expired, in error, completed and any other event reported by the process, such as when a signatory has signed or refused to sign), CONTRACT (activated, cancelled).
enum:
- STATUS_CHANGE
example: STATUS_CHANGE
timestamp:
type: string
format: date-time
description: Original time of event generation in UTC and ISO 8601 format
example: "2025-05-13T13:26:17Z"
responses:
'200':
description: Successful operation.
'401':
description: Authentication failure or the authenticated user doesn't have enough privilege to perform the action.
'500':
description: Internal server error / Technical error.
Test cases
The test cases provided through the sandbox cover the following scenarios.
Errors
Functional errors returned by the API
SLA and availability
The API is available 24x7